summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2026-08-31Merge drm/drm-next into drm-misc-nextThomas Zimmermann
Getting drm-misc-next up to v7.3-rc1. In exynos, there was a conflict in exynos_dbi_bind(). The merge resolves it to the state of commit 3cc8eee9f346 ("drm/exynos: remove dependency on DRM simple helpers"). Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
2026-08-28Merge tag 'drm-next-2026-08-29' of https://gitlab.freedesktop.org/drm/kernelLinus Torvalds
Pull more drm updates from Dave Airlie: "As mentioned last week, an msm pull request fell down the side of the couch or whatever the email equivalent of that is. This has the msm next stuff + the usual fixes for amd/intel. core: - use drm_warn instead of warn msm: - Bindings: - Added Shikra support - Document a840, a704, a722 - Core: - Use drm_client buffers for fbdev emulation - teardown fixes - ARM32 DMA fixup - Remove objects from evict list when re-validated - Bunch of corner case and error path fixes - DPU: - Dropped dev_pm_opp_set_rate(0) preventing burnout - Fixed SSPP offsets of Kaanapali - DP: - Dropped dev_pm_opp_set_rate(0) preventing burnout - Cleaned up core code in preparation for MST support - Fixed prepare() to let Pipewire continue in case of the unplugged cable - GPU: - Add support for a704 - Add support for a722 - HDMI: - Simplifed register access amdgpu: - eGPU fixes - Runtime PM fix - UserQ fixes - Backlight fix - Discovery sysfs fix - Reset handling fixes - Buffer func handling fix for xgmi - VCN boundary check fix - DC lut handling fixes - MES fixes - UVD fix - VCE 3 fix - Enforce isolation fix - HPD fix for VGA/LVDS - DML fix - DCN 6 fixes - DC gpu reset fix amdkfd: - Fix return value - CU occupancy for GFX 11 - CU occupancy for GFX 12/12.1 - Queue bounds checking fix - SVM fixes - CRIU bounds checking fix radeon: - iMac display fix xe: - error message cleanups - i2c global register definitions as dependency for xe/i2c fixes - Media workardound - Add CCS to gt_idle debugfs print - Page fault related fix - i2c related fixes - System Controller mailbox bit fix" * tag 'drm-next-2026-08-29' of https://gitlab.freedesktop.org/drm/kernel: (121 commits) drm/xe/sysctrl: Read mailbox phase bit from hardware drm/xe/i2c: Keep the i2c controller always enabled drm/xe/i2c: Fix the interrupt handling i2c: designware: Global register definitions drm/xe: Reject page faults from non-fault-mode scratch VMs drm/xe/xe_gt_idle: Add CCS to the powergating info print drm/xe: Do not apply WA 14025883347 to media 3503 drm/amd/display: fix dc_lock leak on GPU reset error paths drm/amd/display: Fix redundant GPUVMEnable checks in dcn6 flip schedule drm/amd/display: Fix wrong bytes-per-pixel value for dml2_422_packed_10 drm/amdkfd: guard against NULL restore_mqd in CRIU queue restore drm/amdgpu/userq: fix lock missing for userq fence error set drm/amdkfd: Fix the case that vm range is hole at svm_migrate_copy_to_vram drm/amdkfd: Fix error path at svm_migrate_copy_to_ram drm/amd/display: Log details when failing to register HPD IRQ drm/amd/display: Fix HPD consideration for VGA/LVDS connectors on DCE drm/amdgpu: clamp the isolation index for rings outside a partition drm/amdkfd: Reject zero-sized AQL queue allocations after size halving drm/amdgpu: Fix VCE 3 ring align_mask drm/kfd: Add CU occupancy support to GFX12.1 ...
2026-08-28drm/xe/ggtt: invalidate engine GGTT TLBs for multi-queue GTsTangudu Tilak Tirumalesh
Engines cache GGTT translations in their own TLBs, which the xe_tlb_inval_ggtt() does not touch. After a GGTT unmap the engines can still hit the stale translation and read the old page. Issue an INVAL_FULL (intra vf) invalidation on GGTT unmap, gated on the GT having any multi-queue engine class. v2: - Use xe_gt_has_multi_queue() helper and address nits (Niranjana) v3: - Invalidate both the primary and media GTs, similar to xe_ggtt_invalidate() (Matt Brost) v5: - Guard NULL gt and explain the multi-queue-only engine flush (Niranjana) Assisted-by: Claude:claude-opus-4-8 Reviewed-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Signed-off-by: Tangudu Tilak Tirumalesh <tilak.tirumalesh.tangudu@intel.com> Link: https://patch.msgid.link/20260827082011.3370672-4-tilak.tirumalesh.tangudu@intel.com Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com>
2026-08-28drm/xe/tlb_inval: add xe_tlb_inval_ggtt_full() GGTT invalidation helperTangudu Tilak Tirumalesh
Add xe_tlb_inval_ggtt_full() and its GuC backend send_tlb_inval_ggtt_full() for full engine TLB invalidation within the requesting VF across all engines. v2: - Refactor with new helper xe_tlb_inval_issue_op_wait() and address nits (Niranjana) v3: - Avoid TOCTOU issue around CT state (Matt Brost) v4: - Propagate real send errors instead of masking as -ECANCELED (Sashiko) v5: - Handle -ENOTRECOVERABLE (wedged), drop redundant -ECANCELED (Matt Brost, Niranjana) Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Tangudu Tilak Tirumalesh <tilak.tirumalesh.tangudu@intel.com> Acked-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260827082011.3370672-3-tilak.tirumalesh.tangudu@intel.com Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com>
2026-08-28drm/xe/ggtt: fault on unmapped GGTT for multi-queue platformsTangudu Tilak Tirumalesh
Engines cache GGTT translations in their TLBs. A full context restore on engine switch flushes these, so a stale translation for an unmapped and recycled range does not survive. During a secondary queue append, GuC does a lite-restore and skips the full context restore, so engine TLB invalidations are missed. This was observed while running multi-queue tests on another OS. If unmapped GGTT points to scratch, such a stale access silently reads scratch instead of faulting, masking the error. On multi-queue platforms skip allocating the scratch page so unmapped GGTT holds PTE=0 and faults consistently for the whole boot; other platforms keep scratch and are unaffected. v2: - Add xe_gt_has_multi_queue() helper and address nits (Niranjana) v3: - Drop scratch entirely instead of toggling per-unmap (Matt Brost) v5: - Document the rationale (Matt Roper / Matt Brost) Assisted-by: Claude:claude-opus-4-8 Reviewed-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Signed-off-by: Tangudu Tilak Tirumalesh <tilak.tirumalesh.tangudu@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260827082011.3370672-2-tilak.tirumalesh.tangudu@intel.com Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com>
2026-08-28drm/i915/selftest: Fix a typo in alloc_workqueue callKrzysztof Karas
The workqueue created by test_ipc() was named "i1915-selftest" instead of "i915-selftest". Correct the driver name in the workqueue name. Signed-off-by: Krzysztof Karas <krzysztof.karas@intel.com> Reviewed-by: Janusz Krzysztofik <janusz.krzysztofik@linux.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/20260828100339.72304-2-krzysztof.karas@intel.com
2026-08-28drm/xe/sysctrl: Reuse xe_sysctrl_create_command()Raag Jadav
Now that we have a helper to create sysctrl command, reuse it for threshold crossed events. Signed-off-by: Raag Jadav <raag.jadav@intel.com> Reviewed-by: Riana Tauro <riana.tauro@intel.com> Link: https://patch.msgid.link/20260818135304.497098-6-raag.jadav@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-08-28drm/xe/drm_ras: Wire up error threshold callbacksRaag Jadav
Now that we have get/set error threshold support in xe driver, wire them up to drm_ras so that userspace can make use of the functionality. $ sudo ynl --family drm_ras --do get-error-threshold \ --json '{"node-id":0, "error-id":2}' {'error-id': 2, 'error-name': 'soc-internal', 'error-threshold': 16} $ sudo ynl --family drm_ras --do set-error-threshold \ --json '{"node-id":0, "error-id":2, "error-threshold":8}' None Signed-off-by: Raag Jadav <raag.jadav@intel.com> Reviewed-by: Riana Tauro <riana.tauro@intel.com> Link: https://patch.msgid.link/20260818135304.497098-5-raag.jadav@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-08-28drm/xe/ras: Add support for error thresholdRaag Jadav
System controller allows getting/setting per counter threshold for correctable errors, which it uses to raise error events to the driver. Get/set it using the respective mailbox command. Signed-off-by: Raag Jadav <raag.jadav@intel.com> Reviewed-by: Riana Tauro <riana.tauro@intel.com> Link: https://patch.msgid.link/20260818135304.497098-4-raag.jadav@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-08-28drm/ras: Introduce error thresholdRaag Jadav
Add get-error-threshold and set-error-threshold command support which allows querying/setting error threshold of the counter. Threshold in RAS context means the number of errors the hardware is expected to accumulate before it raises them to software. This is to have a fine grained control over error notifications that are raised by the hardware. Signed-off-by: Raag Jadav <raag.jadav@intel.com> Reviewed-by: Riana Tauro <riana.tauro@intel.com> Acked-by: Joshua Santhosh Ranjan <joshua.santosh.ranjan@intel.com> Link: https://patch.msgid.link/20260818135304.497098-3-raag.jadav@intel.com Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-08-28drm/ras: Cancel and free message on get counter failureRaag Jadav
doit_reply_value() directly returns on get counter failure, which results in stale sk_buff and genetlink header that aren't cleaned up. Fix it and while at it, consolidate error handling using goto. Fixes: c36218dc49f5 ("drm/ras: Introduce the DRM RAS infrastructure over generic netlink") Signed-off-by: Raag Jadav <raag.jadav@intel.com> Reviewed-by: Riana Tauro <riana.tauro@intel.com> Link: https://patch.msgid.link/20260818135304.497098-2-raag.jadav@intel.com Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-08-28Merge tag 'amd-drm-next-7.3-2026-08-27' of ↵Dave Airlie
https://gitlab.freedesktop.org/agd5f/linux into drm-next amd-drm-next-7.3-2026-08-27: amdgpu: - MES fixes - Userq fixes - UVD fix - VCE 3 fix - Enforce isolation fix - HPD fix for VGA/LVDS - DML fix - DCN 6 fixes - DC gpu reset fix amdkfd: - CU occupancy for GFX 11 - CU occupancy for GFX 12/12.1 - Queue bounds checking fix - SVM fixes - CRIU bounds checking fix Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patch.msgid.link/20260827203610.3249084-1-alexander.deucher@amd.com
2026-08-27drm/xe: Add debugfs knob to control GPGPU preemption granularityVarun Gupta
Introduce a per-GT debugfs knob, 'gpgpu_preemption_level', to allow overriding the GPGPU preemption level on a per-context basis for newly created LRCs. Add an RTP rule to enable per-context control via FF_SLICE_CS_CHICKEN1, allowing the preemption level to be programmed directly into the LRC image at CTX_CS_CHICKEN1 during context initialization. v9: - Move the per-context/GT-scoped behavior description from the enum kerneldoc to the gpgpu_preemption_level member kerneldoc, and drop the kzalloc zero-initialization note. (Gustavo) v8: - Encapsulate LRC preemption programming into xe_lrc_set_gpgpu_preemption_level() (Gustavo) - Add xe_gt_WARN and early return for unexpected preemption level values to prevent invalid CS_CHICKEN1 programming. (Gustavo) - Change -EPERM to -EINVAL for MTP fused off check (Gustavo) - Combine FF_SLICE_CS_CHICKEN1 RTP rule using OR macro (Gustavo) v7: - Restrict XEHP_FUSE4 read to Xe2+ primary GTs to prevent invalid Media GT accesses and SR-IOV warnings. (Sashiko) v6: - Add missing xe_gt_printk.h include to fix compilation failure. v5: - Use correct offset for CTX_CS_CHICKEN1. (Matt) - Restrict to the RCS engine. (Matt) - Drop LRC layout table modifications; dummy layouts do not need late context registers. (Matt) - Stash WMTP fuse state at boot to remove pm/forcewake from debugfs. (Matt) - Rename debugfs knob to 'gpgpu_preemption_level'. (Matt) - Use simple_write_to_buffer() and remove unnecessary READ_ONCE/ WRITE_ONCE macros. (Matt) - Do not restrict debugfs visibility for SR-IOV VFs. (Matt) v4 - Fix incorrect NOP padding in the RCS context layout. (Sashiko) v3: - Wrapped XEHP_FUSE4 forcewake read with xe_pm_runtime_get/put to prevent PCIe aborts/timeouts when the GPU is in D3hot/D3cold. (sashiko) - Fixed NOP macro truncation by splitting padding offsets larger than 0x7f into multiple NOPs, ensuring correct context layout. (sashiko) - Converted CTX_CS_CHICKEN1 initialization to a read-modify-write sequence to avoid overwriting golden context mask bits. (sashiko) - Removed the FF_SLICE_CS_CHICKEN1 workaround for CCS engines, as compute engines lack this 3D fixed-function register, which was causing GuC "illegal register" panics on initialization. v2: - Dropped the WA BB/MI_LRI path; per Bspec, CS_CHICKEN1 is context save/restore state at DW 0x00E2, so we map CTX_CS_CHICKEN1 and program it directly in LRC init via xe_lrc_write_ctx_reg(). (Matt) - Split Xe2 CCS context offsets into a dedicated xe2_ccs_offsets array to map CS_CHICKEN1 without polluting other XCS engines. - Converted the debugfs interface from a binary boolean to a multi-option string knob ("default", "mid-thread", "thread-group", "command"). (Gustavo) - Restricted file creation to the Physical Function (!IS_SRIOV_VF). (Gustavo) - Added kernel tainting (TAINT_USER) when deviating from defaults. (Gustavo) - Added power-safe hardware fuse check (FUSE4 register 0x9114[20], CFEG_WMTP_DISABLE) before allowing MTP selection. (Matt) Signed-off-by: Varun Gupta <varun.gupta@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patch.msgid.link/20260827072106.1138741-2-varun.gupta@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2026-08-27Merge tag 'mm-stable-2026-08-26-15-22' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Pull more MM updates from Andrew Morton: - "mm/rmap: index MAP_PRIVATE file-backed folios by anonymous pgoff" (Lorenzo Stoakes) Index MAP_PRIVATE file-backed folios by their anonymous page offset to resolve confusion around reverse mapping for zeroed and CoW'd file-backed memory. Use this new VMA anonymous page offset tracking to eliminate index conflicts and lay the foundation for scalable CoW performance improvements. - "promote mapped executable folios after first usage for MGLRU" (Baolin Wang) Make MGLRU's protection of mapped executable file folios more reliable. Follow the classical LRU's logic, promoting mapped executable file folios after their first usage to give executable code a better chance to stay in memory and improve workload performance. - "mm: vmscan: fix node reclaim ignoring swappiness parameter" (Ridong Chen) Fix per-node proactive reclaim interface's ignoring the swappiness parameter when CONFIG_MEMCG is disabled by consolidating sc_swappiness() into a single function that checks proactive_swappiness regardless of kernel configuration. - "mm/vmscan: reduce lru_lock contention via vmstat-derived scan-balance cost" (Usama Arif) Reduce lru_lock contention in the reclaim path by deriving scan-balance costs from vmstat counters rather than lock-acquired producer updates. Read and decay these cost signals on the reclaim side under a dedicated per-lruvec lock, reducing total LRU lock wait time by over 60% without impacting scan throughput. - "zram: fix zram issues reported by sashiko" (Sergey Senozhatsky) Fix two low-risk zram bugs which Sashiko spotted in drive-by review. - "Honor XA_FLAGS_ACCOUNT in xas_split_alloc() and charge to folio's memcg" (Zi Yan) Fix xas_split_alloc() by enabling target folio memcg charging during splits and adding the missing __GFP_ACCOUNT flag for proper XArray node memory accounting. - "selftests/mm: use pattern matching in .gitignore" (Pratyush Mallick) Replace hardcoded binary names in selftests/mm/.gitignore with a generic pattern-matching rule to automatically ignore generated test files and avoid manual updates when adding new tests. - "mm/page_ext: remove pgdat_page_ext_init()" (Sang-Heon Jeon) Make the incompatibility between FLATMEM and NUMA explicit in mm/Kconfig and remove the unused pgdat_page_ext_init() function. - "zram: fix zstd error paths and add parameter validation" (Haoqin Huang) Clean up zram compression backends by removing redundant error cleanup, adding parameter and dictionary validation, auto-prefixing algorithm error logs, and resetting parameters prior to reinitialization. - "zram: fix stale scan bounds after reinitialization" (Longlong Xia) Prevent out-of-bounds slot accesses during concurrent zram resets by moving table scan bound calculations under dev_lock in writeback_store() and read_block_state(). - "add anon mTHP collapse test cases" (Baolin Wang) Extend selftests helper functions to support arbitrary page orders and add new test cases and options for mTHP collapse in khugepaged. - "selftests/mm: Handle unsupported and transient test conditions" (Muhammad Usama Anjum) Update MM selftests to report a SKIP status instead of a failure when required kernel or filesystem features are unsupported, while adding retry logic for transient page migration errors. - "mm/zswap: Fixes and improves the zswap shrink" (Hao Jia) Fix the missing zswap global shrinker when CONFIG_MEMCG is disabled and extend shrink_memcg() to support batch writeback for improved writeback efficiency. - "alloc_tag: introduce IOCTL-based filtering for MAP" (Suren Baghdasaryan) Introduce an IOCTL-based binary interface for memory allocation profiling that enables kernel-side filtering before per-CPU counter aggregation. This eliminates the text-parsing overhead of /proc/allocinfo and provides up to a 20x speedup by transferring only filtered allocation data to userspace. - "better block swap batching and a different take on swap_ops v5" (Christoph Hellwig) Refactor block swap I/O to use swap_iocb for batching instead of single-bio requests and rebase the swap_ops interface, achieving faster swap throughput during kernel builds. - "mm: kmemleak: reduce transient false positives by confirming leaks" (Catalin Marinas) Reduce false-positive kmemleak reports by combining two kmemleak enhancements that add a second confirmation scan and a configurable minimum unreferenced scan count module parameter. - "mm: kmemleak: default min_unref_scans to 2 for verbose kernels" (Breno Leitao) Auto-scanning kernels can generate false-positive memory leak reports on single scans, so this patch defaults min_unref_scans to 2 when CONFIG_DEBUG_KMEMLEAK_VERBOSE is enabled to require a second confirming scan. - "swap_ops updates" (Christoph Hellwig) Batching I/O for synchronous swap devices causes performance regressions and filesystem-based swap suffers from double-indirection overhead. This series resolves both issues by reintroducing per-folio writes for synchronous swap and allowing filesystems to directly export their own swap_ops. - "mm/khugepaged: several cleanups" (Nico Pache) khugepaged accumulated redundant state-checking patterns and outdated comments following mTHP integration. Introduce dedicated helpers for PTE validation and event counting while refreshing the internal documentation. - "maple_tree: lock checking and clean ups" (Liam Howlett) Syzbot reports incorrectly blame memory management exit paths for locking bugs, maple tree erase operations risk allocation failures without gfp flags and internal documentation lacks clarity. Improve lock error detection, update docs, fix race and allocation edge cases and optimize erase allocations using a fallback to GFP_KERNEL | GFP_NOFAIL. * tag 'mm-stable-2026-08-26-15-22' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm: (172 commits) selftests/proc: make proc-maps-race work with READ_IMPLIES_EXEC memcg: move LRU size accounting on reparenting instead of copying it mm/vmscan: fix comment logic in balance_pgdat maple_tree: add helper mas_make_walkable() maple_tree: avoid extra gap calculation maple_tree: fix argument name in header maple_tree: change two GFP flags in tests maple_tree: document erase and allocations better maple_tree: avoid mas_erase() and mtree_erase() failures maple_tree: document that erase may use GFP_KERNEL for allocations maple_tree: catch race in mas_alloc_cyclic() maple_tree: add bulk parent set helper maple_tree: micro optimisation of mas_wr_store_type() maple_tree: optimise mas_wr_node_store() when not in rcu mode maple_tree: use prefetched value in mas_wr_store_type() maple_tree: clarify comments on mas_nomem() maple_tree: drop MAPLE_ALLOC_SLOTS maple_tree: drop dead code from mas_extend_spanning_null() maple_tree: documentation fix maple_tree: add write lock checking with lockdep sequence numbers ...
2026-08-27drm/xe/sysctrl: Read mailbox phase bit from hardwareAnoop Vijay
The mailbox PHASE bit in SYSCTRL_MB_CTRL is toggled per-message and was tracked in software as sc->phase_bit, reset to 0 on error paths. If the cached value ever drifts from what the hardware last saw, all following messages carry the wrong phase and get silently misread by firmware. Drop the cache and read PHASE directly from SYSCTRL_MB_CTRL before each frame instead, removing xe_sysctrl_mailbox_init() and its call sites along with it. Fixes: 1f95f618182b ("drm/xe/xe_sysctrl: Add System Controller mailbox communication support") Signed-off-by: Anoop Vijay <anoop.c.vijay@intel.com> Reviewed-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patch.msgid.link/20260825172827.3801591-2-anoop.c.vijay@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> (cherry picked from commit 04984fcdbf6876c940c01026a7404c1e9cc91ba7) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-08-27drm/xe/i2c: Keep the i2c controller always enabledHeikki Krogerus
Some platforms make an assumption that the i2c controller's enabled state indicates also the power state of the controller. This can create a problem when the controller is in disabled state, because the hardware may assume incorrectly that it is then also in low-power state. To fix this, the controller is kept enabled by taking over the IC_ENABLE register. The controller has to be disabled when the configuration is updated and when the target address or the slave address are assigned, so disabling it when IC_CON, IC_TAR or IC_SAR registers are programmed, and then re-enabling it again. Fixes: f0e53aadd702 ("drm/xe: Support for I2C attached MCUs") Cc: stable@vger.kernel.org Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patch.msgid.link/20260811121008.1493015-4-heikki.krogerus@linux.intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> (cherry picked from commit 76cc14e2faed1adae20f4ee144ead0e3a7566c49) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-08-27drm/xe/i2c: Fix the interrupt handlingHeikki Krogerus
The platforms that support the interrupt from the I2C adapter can not handle the amount of interrupts the adapter generates because of the way the IRQ is routed in the hardware. The I2C controller driver has to be kept in polling mode because of that. The AMC MCU can still generate critical alerts that have to be handled. The interrupt from SMBus Alert is left enabled and handled separately in the Xe. The alerts from the AMC will cause the device to be declared wedged for now. Fixes: f0e53aadd702 ("drm/xe: Support for I2C attached MCUs") Cc: stable@vger.kernel.org Reviewed-by: Raag Jadav <raag.jadav@intel.com> Co-developed-by: Ramesh Babu B <ramesh.babu.b@intel.com> Signed-off-by: Ramesh Babu B <ramesh.babu.b@intel.com> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://patch.msgid.link/20260811121008.1493015-3-heikki.krogerus@linux.intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> (cherry picked from commit a55b76b8bc2c49b11d753c1c6d06ec3a2c61c85e) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-08-27drm/tegra: Add blend mode propertiesThierry Reding
The default programming in the driver matches the "coverage" blend mode, so add the corresponding pixel blend mode property to let userspace know about it. Tested-by: Jon Hunter <jonathanh@nvidia.com> Acked-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://patch.msgid.link/20260826105421.1825331-1-thierry.reding@kernel.org
2026-08-27drm/amd/display: pull colorops into state when recreating a planeHarry Wentland
[Why] When should_reset_plane() forces a plane's dc_plane_state to be recreated (e.g. on every ALLOW_MODESET commit on DCN < 3.2), fill_dc_plane_attributes() re-derives the plane's color pipeline from the DRM colorop states. The per-stage helpers look up each colorop with for_each_new_colorop_in_state(), which only iterates colorops attached to the current commit. If userspace didn't touch color in that commit the colorops are absent, so the fixed matrix (YUV->RGB), shaper, 3D LUT and regamma all silently fall back to bypass. This corrupts the plane's colors - e.g. an HDR P010 video losing its color-space conversion - until the pipeline happens to be re-committed. [How] When recreating a plane that has an active color_pipeline, call drm_atomic_add_affected_colorops() so the plane's colorops are pulled into the commit and the derivation sees the current pipeline instead of defaulting every stage to bypass. This mirrors what the core already does on a modeset via drm_atomic_add_affected_planes(). Assisted-by: Copilot:claude-opus-4.8 Signed-off-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Alex Hung <alex.hung@amd.com> Link: https://patch.msgid.link/20260825153539.213495-1-harry.wentland@amd.com
2026-08-27drm/amd/display: Force GAMCOR for subsampled surfaces with PQ/Gamma22/HLGHarry Wentland
The ROM early-return checks for PQ, Gamma 2.2, and HLG in mod_color_calculate_degamma_params() do not consider the map_user_ramp parameter. When map_user_ramp is true (indicating a subsampled surface that requires post-scaler degamma via GAMCOR), the function still takes the ROM path, programming PRE_DEGAM instead. For subsampled formats the chroma channels must be upsampled by the scaler before degamma is applied. PRE_DEGAM sits before the scaler in the pipeline (CNVC domain), while GAMCOR sits after it (CM domain). Using the ROM for subsampled surfaces means degamma is applied to subsampled chroma before upsampling, producing incorrect results. Fix by gating the dcn_arch ROM capability checks on !map_user_ramp, forcing PQ/Gamma22/HLG through the GAMCOR LUT path when the surface is subsampled. Fixes: a8bf71649088 ("drm/amd/display: Internal refactoring to abstract color caps") Cc: stable@vger.kernel.org Assisted-by: Copilot:claude-opus-4.6 Signed-off-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Alex Hung <alex.hung@amd.com> Tested-by: Robert Mader <robert.mader@collabora.com> Link: https://patch.msgid.link/20260814211816.1219597-11-harry.wentland@amd.com
2026-08-27drm/amd/display: Set color_space to plane_infosHarry Wentland
DC looks at plane_info structs. For legacy drm_plane COLOR_ENCODING and COLOR_RANGE this was done in fill_dc_plane_info_and_addr's call to fill_plane_color_attributes. Assisted-by: Claude:claude-sonnet-4.5 Signed-off-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Alex Hung <alex.hung@amd.com> Tested-by: Robert Mader <robert.mader@collabora.com> Link: https://patch.msgid.link/20260814211816.1219597-10-harry.wentland@amd.com
2026-08-27drm/amd/display: Check actual state during commit_tailHarry Wentland
Previously we checked the plane_state->state's plane_color_pipeline client config when determining whether fill_plane_color_attributes should run, i.e., whether we had a plane color pipeline and should use that code for handling fixed matrix properties, or whether we should look at legacy plane encoding and range. The problem is that we also call this during commit_tail, during which plane_state doesn't have the state backpointer. This meant that during commit_tail we'd look at the legacy plane COLOR_RANGE and COLOR_ENCODING values and overwrite what we pulled from the fixed matrix colorop in atomic_check previously. Instead pass the drm_atomic_state in explicitly and check that. Assisted-by:Claude:claude-sonnet-4.5 Signed-off-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Alex Hung <alex.hung@amd.com> Tested-by: Robert Mader <robert.mader@collabora.com> Link: https://patch.msgid.link/20260814211816.1219597-9-harry.wentland@amd.com
2026-08-27drm/amd/display: Use GAMCOR for first TF if YUV conversion is neededHarry Wentland
For subsampled formats we need to use GAMCOR instead of the DEGAM block. The color module can create a LUT for that if we set map_user_ramp to true. So do that when we have subsampled formats. Assisted-by: Claude:claude-sonnet-4.5 Signed-off-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Alex Hung <alex.hung@amd.com> Tested-by: Robert Mader <robert.mader@collabora.com> Link: https://patch.msgid.link/20260814211816.1219597-8-harry.wentland@amd.com
2026-08-27drm/amd/display: Implement fixed matrix colorop color space mappingHarry Wentland
Add __set_dm_plane_colorop_fixed_matrix() which maps the fixed matrix type enum to the appropriate dc_color_space for DC programming: YCBCR601_FULL_RGB -> COLOR_SPACE_YCBCR601 YCBCR601_LIMITED_RGB -> COLOR_SPACE_YCBCR601_LIMITED YCBCR709_FULL_RGB -> COLOR_SPACE_YCBCR709 YCBCR709_LIMITED_RGB -> COLOR_SPACE_YCBCR709_LIMITED YCBCR2020_FULL_RGB_NC -> COLOR_SPACE_2020_YCBCR_FULL YCBCR2020_LIMITED_RGB_NC -> COLOR_SPACE_2020_YCBCR_LIMITED When the fixed matrix is bypassed, color_space is set to COLOR_SPACE_UNKNOWN. Update amdgpu_dm_plane_set_colorop_properties() to process the fixed matrix colorop first (before DEGAM), matching the new pipeline order. Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Alex Hung <alex.hung@amd.com> Tested-by: Robert Mader <robert.mader@collabora.com> Link: https://patch.msgid.link/20260814211816.1219597-7-harry.wentland@amd.com
2026-08-27drm/amd/display: Add fixed matrix colorop to color pipelineHarry Wentland
Insert a fixed matrix colorop as the first operation in the amdgpu color pipeline, before the existing DEGAM 1D curve. This allows userspace to select YUV-to-RGB conversion via the color pipeline for YCbCr framebuffers. The fixed matrix colorop advertises support for all six YUV-to-RGB conversion presets: - YUV601/709/2020 full-range to RGB - YUV601/709/2020 limited-range to RGB Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Alex Hung <alex.hung@amd.com> Tested-by: Robert Mader <robert.mader@collabora.com> Link: https://patch.msgid.link/20260814211816.1219597-6-harry.wentland@amd.com
2026-08-27drm/vkms: Add atomic check and matrix handling for fixed matrix coloropHarry Wentland
In vkms_plane_atomic_check(), validate that when a color pipeline is active and the framebuffer format is YUV: - The first colorop must be DRM_COLOROP_FIXED_MATRIX - The fixed matrix colorop must not be bypassed In vkms_plane_atomic_update(), when a color pipeline is active, read the fixed_matrix_type from the first colorop state and map it to the appropriate (color_encoding, color_range) pair for the existing get_conversion_matrix_to_argb_u16() function. In apply_colorop(), add a no-op case for DRM_COLOROP_FIXED_MATRIX since the actual YUV-to-RGB conversion is already performed at format read time via the conversion matrix. Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Alex Hung <alex.hung@amd.com> Reviewed-by: Robert Mader <robert.mader@collabora.com> Link: https://patch.msgid.link/20260814211816.1219597-5-harry.wentland@amd.com
2026-08-27drm/vkms: Add fixed matrix colorop to color pipelineHarry Wentland
Insert a fixed matrix colorop as the first operation in the VKMS color pipeline, before the existing 1D curve. This allows userspace to select YUV-to-RGB conversion via the color pipeline for YCbCr framebuffers. The CSC Fixed Matrix colorop advertises support for all six YUV-to-RGB conversion presets: - YUV601/709/2020 full-range to RGB - YUV601/709/2020 limited-range to RGB Bump MAX_COLOR_PIPELINE_OPS from 4 to 5 to accommodate the new op. Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Alex Hung <alex.hung@amd.com> Reviewed-by: Robert Mader <robert.mader@collabora.com> Link: https://patch.msgid.link/20260814211816.1219597-4-harry.wentland@amd.com
2026-08-27drm/vkms: Fix limited-range YCbCr to RGB conversion scalingHarry Wentland
The limited-/studio-range YCbCr to RGB conversion matrices were generated with colour.matrix_YCbCr(is_legal=True, bits=8), which normalises the narrow range by 2^bits (256 for 8-bit) rather than by the full-range maximum 2^bits - 1 (255). As a result the luma scale was 256/219 and the chroma scale 256/224 instead of the correct 255/219 and 255/224. This over-scales every limited-range conversion by a factor of 256/255, producing an error of up to ~3/255 (8-bit) and causing IGT tests that compare software-computed surfaces against VKMS-processed ones to fail. Recompute the three limited-range matrices from first principles rather than relying on colour's is_legal scaling: 1. Start from the standard ITU-R YCbCr -> RGB relations for the luma weights Kr, Kb (Kg = 1 - Kr - Kb) of each encoding (BT.601, BT.709 and BT.2020 non-constant luminance). These are the same relations that produce the existing full-range matrices. 2. Expand the studio input range to full range relative to a full-range maximum of 2^n - 1: the luma coefficient by 255/(235 - 16) and the chroma coefficients by 255/(240 - 16). This matches the DRM UAPI definition and IGT's igt_ycbcr_to_rgb_matrix(). 3. Convert each coefficient to S31.32 fixed point (round(coeff * 2^32)). Update the limited-range reference values in the vkms-format KUnit test accordingly. Provide a python script to show how the kunit test value are calculated. Fixes: fe22d21e9342 ("drm/vkms: Add YUV support") Assisted-by: Copilot:claude-opus-4.8 Signed-off-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Alex Hung <alex.hung@amd.com> Tested-by: Robert Mader <robert.mader@collabora.com> Link: https://patch.msgid.link/20260814211816.1219597-3-harry.wentland@amd.com
2026-08-27drm/colorop: Add DRM_COLOROP_FIXED_MATRIXChaitanya Kumar Borah
Introduce DRM_COLOROP_FIXED_MATRIX, a new colorop type representing a hardware that performs a fixed matrix operation. Unlike CTM-based colorops, this block does not expose programmable coefficients. Instead, userspace selects one of the predefined hardware modes via a new FIXED_MATRIX_TYPE enum property. Supported modes include common YCbCr->RGB and RGB709->RGB2020 conversions. v5: - Drop YCbCr limited to full and RGB709 to RGB2020 matrices until we have non-IGT userspace that shows their use (Robert) v4: - Add limited-range YCbCr-RGB conversion matrix enums (Robert) - Document matrix values (Pekka) - Clarify RGB709 to RGB2020 is a full-range matrix (Pekka) - Fix confusing "CSC preset" doc (Pekka) v2: - Naming changes (Pekka) v3: - Fix NC matrix enum name and string (Melissa) - Rebase Co-developed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Signed-off-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Melissa Wen <mwen@igalia.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Robert Mader <robert.mader@collabora.com> Reviewed-by: Alex Hung <alex.hung@amd.com> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.com> Link: https://patch.msgid.link/20260814211816.1219597-2-harry.wentland@amd.com
2026-08-27drm/xe/xe_gt_idle: fix vecs config for powergating infoAshutosh Dixit
vecs configuration for newer platforms (media version >= 35) is different. Fix powergating info for these platforms. Bspec: 67103, 77977 Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Reviewed-by: Badal Nilawar <badal.nilawar@intel.com> Link: https://patch.msgid.link/20260818050041.448014-1-ashutosh.dixit@intel.com
2026-08-27drm/xe: Reject page faults from non-fault-mode scratch VMsArvind Yadav
Having scratch enabled does not make a VM capable of handling recoverable page faults. Allowing scratch VMs through the ASID lookup also admits dma-fence mode VMs. If such a VM faults on an already valid VMA, the handler reports success without fixing the fault, causing the GPU to retry indefinitely. Only allow fault-mode VMs through the ASID lookup. Fault-mode VMs using scratch remain supported, while faults from 3D VMs are rejected. Fixes: ad9843aac91a ("drm/xe/madvise: Implement purgeable buffer object support") Cc: Matthew Brost <matthew.brost@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Suggested-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Arvind Yadav <arvind.yadav@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260820065445.567228-1-arvind.yadav@intel.com (cherry picked from commit bfb24a06405b652d37831f3fb66b71d33a6605de) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-08-27drm/xe/xe_gt_idle: Add CCS to the powergating info printBalasubramani Vivekanandan
While reading the main GT powergating info from debugfs, include both RCS and CCS engine masks. Fixes: 0914c1e45d3a1 ("drm/xe/xe_gt_idle: add debugfs entry for powergating info") Signed-off-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Link: https://patch.msgid.link/20260819073457.1812722-2-balasubramani.vivekanandan@intel.com Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> (cherry picked from commit 8899e413c5ab85443ec9bbc50cffe924c6b596de) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-08-27drm/xe: Do not apply WA 14025883347 to media 3503Daniele Ceraolo Spurio
The database was updated and the WA is no longer listed as applicable to media 3503, so don't enable it there. Fixes: c57db41b8d2c ("drm/xe/guc: Add Wa_14025883347 for GuC DMA failure on reset") Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Sk Anirban <sk.anirban@intel.com> Cc: Badal Nilawar <badal.nilawar@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patch.msgid.link/20260818213520.283063-1-daniele.ceraolospurio@intel.com (cherry picked from commit fae59d5de5de39bc51ac2839f74970312e0c8905) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-08-27gpu/tests/buddy: add dirty tracker performance KUnit testArunpravin Paneer Selvam
Add gpu_test_buddy_dirty_tracker_performance to demonstrate the key advantage of the decoupled dirty-tracker design over the old dual-tree / force_merge approach. The test runs two scenarios on a 4 GiB pool after alternating clear/dirty fragmentation at 4 KiB granularity: 1. Contiguous 2 GiB alloc: smaller than the 4 GiB span so it routes through the contiguous allocator rather than the exact-range fast path. The old design requires __force_merge() to rebuild the block; the new design coalesces during free() so the alloc is O(log N). old (force_merge) - 45 ms dirty tracker design - 11 ms 2. Repeated 256 KiB alloc throughput: the old design pays __force_merge() on every alloc; the new design does not. old (force_merge) - 86 ms dirty tracker design - 20 ms v2: - Force a contiguous 256 KiB allocation in the repeated-alloc loop so the baseline actually exercises __force_merge(). (sashiko) v3: - Make the first test allocate 2 GiB instead of the full 4 GiB pool, so it really uses the contiguous path; update the numbers. (sashiko) Assisted-by: Claude:claude-opus-4-8 Cc: Matthew Auld <matthew.auld@intel.com> Cc: Christian König <christian.koenig@amd.com> Signed-off-by: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patch.msgid.link/20260825172432.80355-2-Arunpravin.PaneerSelvam@amd.com
2026-08-27gpu/buddy: replace dual-tree/force_merge with decoupled dirty trackerArunpravin Paneer Selvam
The current buddy allocator maintains separate clear_tree[] and dirty_tree[] rbtrees per order, preventing coalescing between cleared and dirty buddies. Under mixed workloads, this creates a merge barrier: adjacent buddies frequently end up split across trees, forcing reliance on __force_merge() during allocation. __force_merge() performs an O(N x max_order) scan under the VRAM manager lock, leading to allocation stalls and failures for large contiguous requests even when sufficient total free memory is available. Solution Replace the dual-tree design with: - A single free_tree[order] rbtree for dirty and mixed free blocks (fully cleared free blocks float outside this tree) - A lightweight out-of-band dirty tracker (gpu_dirty_tracker) Fully cleared free blocks are tracked outside the buddy trees using an augmented interval rbtree, enabling O(log E) lookup of the largest cleared extents. Buddy coalescing is now unconditional in __gpu_buddy_free(), regardless of clear/dirty state. This removes the merge barrier and eliminates the need for __force_merge(). Benefits - Correct high-order allocations after mixed clear/dirty workloads - Elimination of O(N x max_order) merge cost from the allocation path - O(log E) cleared-extent lookup replacing O(N) scans - Predictable allocation latency under fragmentation - Reduced complexity with a single tree per order Test: dEQP-VK.memory.allocation.basic.size_8KiB.reverse.count_4000 Below data is from /sys/kernel/debug/dri/1/amdgpu_vram_mm: Base (dual-tree), before VKCTS test: order- 6 free: 6 MiB, blocks: 26 order- 5 free: 1 MiB, blocks: 15 order- 4 free: 960 KiB, blocks: 15 order- 3 free: 5 MiB, blocks: 171 order- 2 free: 2 MiB, blocks: 176 order- 1 free: 1 MiB, blocks: 165 order- 0 free: 16 KiB, blocks: 4 Base (dual-tree), after VKCTS test: order- 6 free: 768 KiB, blocks: 3 order- 5 free: 499 MiB, blocks: 3999 order- 4 free: 250 MiB, blocks: 4001 order- 3 free: 129 MiB, blocks: 4157 order- 2 free: 65 MiB, blocks: 4161 order- 1 free: 63 MiB, blocks: 8138 order- 0 free: 20 KiB, blocks: 5 Dirty tracker, before VKCTS test: order- 6 free: 4 MiB, blocks: 19 order- 5 free: 2 MiB, blocks: 18 order- 4 free: 704 KiB, blocks: 11 order- 3 free: 5 MiB, blocks: 168 order- 2 free: 2 MiB, blocks: 174 order- 1 free: 1 MiB, blocks: 167 order- 0 free: 32 KiB, blocks: 8 Dirty tracker, after VKCTS test: order- 6 free: 4 MiB, blocks: 19 order- 5 free: 2 MiB, blocks: 18 order- 4 free: 704 KiB, blocks: 11 order- 3 free: 5 MiB, blocks: 168 order- 2 free: 2 MiB, blocks: 174 order- 1 free: 1 MiB, blocks: 167 order- 0 free: 28 KiB, blocks: 7 v2: - Code-style cleanup and minor refactoring - Renamed locals for clarity v3: - Keep cleared blocks inside free_tree[] instead of floating them. - Add subtree_has_dirty rbtree augment for O(log N) dirty-first walk. v4: - Fixed checkpatch warnings. - Optimized gpu_buddy_reset_clear() to a single post-order walk that flips block headers and recomputes the rbtree augment in one pass. - Propagate subtree_max_size top-down in insert_extent() so ancestors are not left with stale values on no-rotation inserts. (sashiko) - Drop the whole extent in gpu_dirty_tracker_mark_dirty() when the inside-split allocation fails, avoiding a stale clear claim. (sashiko) - Make gpu_dirty_tracker_find() alignment-aware and fall back to the dirty tree on steered failure to avoid spurious -ENOSPC. (sashiko) v5: - Track dirty extents instead of cleared ones: steer dirty allocs onto tracked dirty windows and pick clear allocs via a free-tree augment, avoiding clear-memory wastage by keeping cleared free blocks untouched during dirty allocation. v6: - Make __alloc_range_bias() return the highest/right-most address by default, establishing top-down as the intended placement for range-biased allocations. - Honour GPU_BUDDY_CLEAR_ALLOCATION in __alloc_range_bias() by steering the descent towards clear subtrees for non-top-down clear requests. (sashiko) - Skip dirty-tracker steering for offset-aligned requests so they keep their min_block_size alignment. (sashiko) - sashiko reported that the __GFP_NOFAIL dirty-extent allocations on the free path could deadlock during memory reclaim, since that is a GFP_KERNEL allocation on the free path; move to a per-tracker mempool so extent nodes are guaranteed without __GFP_NOFAIL. (sashiko) - Derive each free block's clear/dirty class from the blocks already in hand on split, free, alloc, trim and init instead of querying the dirty tracker, removing the tracker lookups from the hot paths. v7: - Preserve mixed-block clear state in __gpu_buddy_free() when a mixed split child is re-merged after an undone split. (sashiko) - Prefer a fully-clear block over a mixed one of the same order via a single ordered clear-state max augment on free_tree[]. v8: - Coalesce contiguous dirty blocks in __gpu_buddy_free_list() into one dirty extent update instead of one mark_dirty() per block. (Matthew) v9: - Reset has_clear on allocation so a mixed block taken whole and later freed fully dirty is not re-tracked as mixed. (sashiko) v10: - Use a plain slab allocation for dirty extents; skip and log once on failure. (Matthew) - Assert a non-zero size in the dirty-tracker range helpers. (Matthew) - Drop the cached clear_avail member; derive it on demand. (Matthew) - Collapse the two dirty branches of gpu_buddy_reset_clear(). (Matthew) - Move the gpu_block_state enum above the gpu_buddy_block kernel-doc so the doc directly precedes its struct. (Matthew) - Mark the gpu_dirty_tracker struct private. (Matthew) - Preserve a block's clear state on non-clear allocation instead of force-dirtying it. (Matthew) - Drop the redundant header clear in gpu_buddy_block_trim(). (Matthew) v11: - Assert the manager lock is held in gpu_buddy_clear_avail(). (Matthew) Assisted-by: Claude:claude-opus-4-8 Cc: Matthew Auld <matthew.auld@intel.com> Cc: Christian König <christian.koenig@amd.com> Signed-off-by: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patch.msgid.link/20260825172432.80355-1-Arunpravin.PaneerSelvam@amd.com
2026-08-27drm/i915/cdclk: Hoist intel_cdclk_{pre,post}_notify() calls upwardsVille Syrjälä
Now that intel_cdclk_{pre,post}_notify() are implemented via vfuncs there is no need to keep them inside the .set_cdclk() hooks. Move the calls one level up to intel_cdclk_set_cdclk(). We do need to adjust {skl,bxt}_cdclk_(un)init_hw() to call the wrapper rather than the low level implementation directly, or else they would not do the pcode notification anymore. The two slight functional changes here are: - bdw_set_cdclk() might theoretically bail out after doing the pre notification, but that codepath would only come into play if the hardware is seriously misprogrammed, so should never happen - cdclk hw readout is still done from .set_cdclk(), so that now happens before the post notify vs. previously the readout happened before it. This should not matter as the readout is not affected by the post notify (since we can't actually read out anything from pcode). Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260826134033.13976-15-ville.syrjala@linux.intel.com
2026-08-27drm/i915/cdclk: Introduce CDCLK .{pre,post}_notify() vfuncsVille Syrjälä
Turn the cdclk pcode pre/post notify functions into vfuncs. Mainly to get rid of the hideous if-ladders in bxt_set_cdclk(). DG2 is currently doing its own thing with its pcode notify funcs so can't be converted yet. And MTL+ go via the pmdemand stuff so this is all supposedly handled elsewhere. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260826134033.13976-14-ville.syrjala@linux.intel.com
2026-08-27drm/i915/cdclk: Extract bxt_cdclk_pcode_{pre,post}_notify()Ville Syrjälä
Extract the BXT/GLK pcode notify stuff to a few small helpers. The plan is to unify these between all the platforms and turn them into vfuncs. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260826134033.13976-13-ville.syrjala@linux.intel.com
2026-08-27drm/i915/cdclk: Extract skl_cdclk_pcode_{pre,post}_notify()Ville Syrjälä
Extract the SKL/ICL+ pcode notify stuff to a few small helpers. The plan is to unify these between all the platforms and turn them into vfuncs. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260826134033.13976-12-ville.syrjala@linux.intel.com
2026-08-27drm/i915/cdclk: Extract bdw_cdclk_pcode_{pre,post}_notify()Ville Syrjälä
Extract the BDW pcode notify stuff to a few small helpers. The plan is to unify these between all the platforms and turn them into vfuncs. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260826134033.13976-11-ville.syrjala@linux.intel.com
2026-08-27drm/i915/cdclk: Unify pcode related debugsVille Syrjälä
The debug spew for the cdclk pcode per/post notify is very inconsistent between different platforms. Unify it all to the same form. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260826134033.13976-10-ville.syrjala@linux.intel.com
2026-08-27drm/i915/cdclk: Unify the pcode pre/post notify in bxt_set_cdclk()Ville Syrjälä
The control flow between the pcode pre and post notifications in bxt_set_cdclk() is written in two different ways, even though they end up doing the same thing. Unify the code. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260826134033.13976-9-ville.syrjala@linux.intel.com
2026-08-27drm/i915/cdclk: s/intel_/dg2_/ for DG2 specific stuffVille Syrjälä
intel_pcode_*notify() are all DG2 specific code. Rename them to have a dg2_ namespace. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260826134033.13976-8-ville.syrjala@linux.intel.com
2026-08-27drm/i915/cdclk: Drop pointless platform check from bxt_set_cdclk()Ville Syrjälä
Overwrite cdclk.hw.voltage_level from intel_update_cdclk() at the end on bxt_set_cdclk() also on bxt/glk. While this isn't actually necessary due to bxt/glk not having any extra DDI based voltage level requirements, it does avoid one less silly 'if' in the code. On icl+ the value derived by bxt_get_cdclk() may not be correct if the voltage level was bumped up due to DDI requirements, thus overwriting the assumed value is crucial there. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260826134033.13976-7-ville.syrjala@linux.intel.com
2026-08-27drm/i915/cdclk: Stop forcing voltage level to 3 all the time on DG2Ville Syrjälä
SKL_CDCLK_PREPARE_FOR_CHANGE == DISPLAY_TO_PCODE_VOLTAGE(3) so we are currently forcing the voltage level to 3 all the time on DG2. Remove SKL_CDCLK_PREPARE_FOR_CHANGE from the mask to avoid this. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260826134033.13976-6-ville.syrjala@linux.intel.com
2026-08-27drm/i915/cdclk: Notify DG2 pcode about pipe power wells regardless of CDCLKVille Syrjälä
We're currently skipping the pcode notifies on DG2 if the CDCLK isn't changing while the power well counts would still need updating. Do the pcode notifications also for pure pipe power well changes. The lower level intel_set_cdclk() will skip doing any real work if the actual CDCLK stuff doesn't need to change, so it's fine to call it even if only the power wells need updating. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260826134033.13976-5-ville.syrjala@linux.intel.com
2026-08-27drm/i915/cdclk: Do the DG2 CDCLK/pipe power well notify properlyVille Syrjälä
The pcode post notify needs to happen after the CDCLK has been changed, not before. Also move the pre_notify call a bit for the sake of symmetry. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260826134033.13976-4-ville.syrjala@linux.intel.com
2026-08-27drm/i915/cdclk: Pass CDCLK in MHz to pcode on DG2Ville Syrjälä
We are currently trying to pass the CDCLK in kHz to the pcode on DG2, while the pcode expects a value in MHz units. Adjust the units appropriately. v2: Call it 'cdclk_mhz' (Jani) Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260826134033.13976-3-ville.syrjala@linux.intel.com
2026-08-27drm/i915/cdclk: Don't bail if pcode post nofify failsVille Syrjälä
We already changed the actual cdclk frequency by the time we do the pcode post notify. So skipping the subsequent readout is plain wrong. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260826134033.13976-2-ville.syrjala@linux.intel.com
2026-08-27drm/i915/cdclk: Fix dg2_power_well_count() return typeVille Syrjälä
dg2_power_well_count() is supposed to return an integer, not a boolean. Make it so. Fixes: 9112ce99c1d7 ("drm/i915/cdclk: Extract dg2_power_well_count()") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260826143100.19401-1-ville.syrjala@linux.intel.com Reviewed-by: Matt Roper <matthew.d.roper@intel.com>