summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2026-08-31drm/sysfb: Clear entire framebuffer in atomic_disableShixiong Ou
drm_sysfb_plane_helper_atomic_disable() previously used plane_state->src_* coordinates to construct the clear rectangle, which depends on user-controlled input. Instead, clear the entire visible framebuffer region using fb_mode dimensions, and use drm_format_info_min_pitch() to compute the safe per-line clear size without touching non-visible bytes at the end of each line. Signed-off-by: Shixiong Ou <oushixiong@kylinos.cn> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260826075613.483617-1-oushixiong1025@163.com
2026-08-31Merge tag 'v7.3-rc1' into drm-rust-nextDanilo Krummrich
Merge v7.3-rc1 into drm-rust-next to start the next cycle. Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-08-31drm/ast: DisplayPort edid supports 256 bytesJammy Huang
DisplayPort supports EDID up to 256 bytes (blocks 0 and 1). Update the block check to allow these two blocks. For any block beyond that (i.e. the monitor's EDID is larger than the 256 bytes ASPEED DP can hold), report it as an all-zero block instead of a read failure. Also remove the manual checksum/extension-count patch of block 0's last four bytes. That code was already dead, so the condition can never be true. Signed-off-by: Jammy Huang <jammy_huang@aspeedtech.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260819-upstream_ast_dp_edid-v3-1-15d36c28afe2@aspeedtech.com
2026-08-31drm/i915: Guard against NULL driver_data in i915_pci_probe()Deepanshu Kartikey
pci_match_device() can return the dummy pci_device_id_any entry when a device is force-bound via sysfs driver_override, in which case ->driver_data is unset (NULL). i915_pci_probe() casts it to struct intel_device_info * unconditionally and dereferences intel_info->require_force_probe, causing a NULL-ptr-deref. Reported-by: syzbot+db96c5ff032f4292a8dc@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=db96c5ff032f4292a8dc Tested-by: syzbot+db96c5ff032f4292a8dc@syzkaller.appspotmail.com Cc: stable@vger.kernel.org Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com> Link: https://patch.msgid.link/20260813064902.367504-1-kartikey406@gmail.com Signed-off-by: Jani Nikula <jani.nikula@intel.com> (cherry picked from commit 2727922084672cc274ecea726ea00363c2893731) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-08-31drm/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> (cherry picked from commit dcf423710d0253d7d729c3992bbae0c6197c9c22) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-08-31drm/i915/cdclk: Avoid spurious cdclk sanitization on PTL+Ville Syrjälä
Apparently PTL+ no longer has the cd2x pipe select field in CDCLK_CTL. Take that into account during CDCLK sanitization. This currently triggers a spurious CDCLK sanitization during driver load on PTL+ which will causes a visible glitch on all active displays. Cc: stable@vger.kernel.org Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/8550 Fixes: 2ee8dbd880b1 ("drm/i915/cdclk: Fix up CDCLK_FREQ_DECIMAL without a full PLL re-enable") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260717155107.17801-1-ville.syrjala@linux.intel.com Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> (cherry picked from commit 1786d26887817a779641d3a093c66ac91382113b) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-08-31drm/i915/display: Clear SEL_FETCH_PLANE_CTL on plane disableNemesa Garg
icl_plane_disable_sel_fetch_arm() wrote SEL_FETCH_PLANE_CTL = 0 only when crtc_state->enable_psr2_sel_fetch was set. If a plane was disabled after selective fetch had been turned off, the guard fired early and left the register's enable bit set in hardware. The bit is harmless until selective fetch is re-enabled. When it is, the hardware resumes fetching for the now-disabled plane and keeps its old DDB range reserved. i9xx_cursor_disable_sel_fetch_arm() has the same guard on SEL_FETCH_CUR_CTL and is fixed the same way. v2: Add same check for cursor also. [sashiko] Cc: stable@vger.kernel.org Fixes: b1f5279b5981 ("drm/i915/psr: Move plane sel fetch configuration into plane source files") Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/8739 Assisted-by: GitHub-Copilot:claude-opus-4.6 Signed-off-by: Nemesa Garg <nemesa.garg@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Animesh Manna <animesh.manna@intel.com> Link: https://patch.msgid.link/20260818095149.2172935-1-nemesa.garg@intel.com (cherry picked from commit 600a7c9d40e5e0c5544f42d1c9592c8d15224dc0) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-08-31drm/i915/lt_phy: program DDI_CLK_VALFREQ with DDI clock frequencySuraj Kandpal
DDI_CLK_VALFREQ is programmed with the port clock, which for DP is the symbol clock computed assuming 8b/10b encoding (link_rate / 10). For DP 128b/132b (UHBR) rates and for HDMI FRL the port clock needs to be modified. DDI_CLK_VALFREQ does not have any functional impact on H/w, it only records the frequency S/w intends to set. Use intel_ddi_link_symbol_clock() to write the correct DDI clock in kHz Fixes: 5ec58d714935 ("drm/i915/lt_phy: Add .enable_clock hook on DDI") Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patch.msgid.link/20260811175844.2613721-4-suraj.kandpal@intel.com (cherry picked from commit eaed815ca3483c227e4ec80b86d1b3ce5c2508be) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-08-31drm/i915/cx0: program DDI_CLK_VALFREQ with DDI clock frequencySuraj Kandpal
DDI_CLK_VALFREQ is programmed with the port clock, which for DP is the symbol clock computed assuming 8b/10b encoding (link_rate / 10). For DP 128b/132b (UHBR) rates and for HDMI FRL the port clock needs to be modfied. DDI_CLK_VALFREQ does not have any functional impact on H/w, it only records the frequency S/w intends to set. Use intel_ddi_link_symbol_clock() to write the correct DDI clock in kHz. Fixes: 51390cc0e00a ("drm/i915/mtl: Add Support for C10 PHY message bus and pll programming") Fixes: 73fc3abcb797 ("drm/i915/mtl: Enabling/disabling sequence Thunderbolt pll") Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patch.msgid.link/20260811175844.2613721-3-suraj.kandpal@intel.com (cherry picked from commit 9ac3ee6c0f92cd09893bd442964fb6b0d6813b5e) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-08-31drm/i915/ddi: add helper to compute DDI clock frequencySuraj Kandpal
Add intel_ddi_link_symbol_clock() to return the DDI clock frequency for a given port clock: DP 8b/10b : rate DP 128b/132b (UHBR) : (10 / 32) * rate HDMI FRL : (10 / 18) * rate HDMI TMDS : rate The DP case reuses intel_dp_link_symbol_clock(). This will help in upcoming commits to decide value to be written in DDI_CLK_VALFREQ. Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patch.msgid.link/20260811175844.2613721-2-suraj.kandpal@intel.com (cherry picked from commit 5abc20e39dd074e8696387ca6871d6e432baf0cd) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-08-31drm/i915/dp_mst: Remove duplicate intel_pfit_compute_config() callChaitanya Kumar Borah
mst_stream_compute_config() called intel_pfit_compute_config() twice in a row. commit 5ce9ac1531b8 ("drm/i915/mst: Call intel_pfit_compute_config() for sharpness filter") was erroneously cherry-picked to the fixes tree while commit ca97f5546f19 ("drm/i915/mst: Call intel_pfit_compute_config() for sharpness filter") was already in there. Drop the redundant duplicate call. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Nemesa Garg <nemesa.garg@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Fixes: 5ce9ac1531b8 ("drm/i915/mst: Call intel_pfit_compute_config() for sharpness filter") Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Reviewed-by: Nemesa Garg <nemesa.garg@intel.com> Link: https://patch.msgid.link/20260806074819.2631970-1-chaitanya.kumar.borah@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> [Rodrigo: adjusted commit message] (cherry picked from commit ea9f3470d33602fb776ea55443467baacf66f23a) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-08-31drm/xe/pcode: match argument naming with PCODE_DATAxMichał Grzelak
Variable naming of val and val1 should match register macro naming. For xe, register macro naming of PCODE_DATA0 and PCODE_DATA1 is already synced with register name. Nevertheless there are still functions declaring val and val1. Rename val into val0 in functions declaring val1 in xe. v4->v5 - clean changelog's versioning v3->v4 - split i915 changes from xe (Jani) v2->v3 - resolve conflict from rebase v1->v2 - rebase onto drm-tip (Jani) Bspec: 19978, 19979 Suggested-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Michał Grzelak <michal.grzelak@intel.com> Link: https://patch.msgid.link/20260828190956.2622350-3-michal.grzelak@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-08-31drm/i915/pcode: rename GEN6_PCODE_DATA to match specMichał Grzelak
Variable naming of val and val1 should match register macro naming. Historically, corresponding macros were named GEN6_PCODE_DATA and GEN6_PCODE_DATA1. Rename register macro GEN6_PCODE_DATA to GEN6_PCODE_DATA0 since spec appended '0' to the register name. Rename val into val0 in functions declaring val1 for both i915-specific and shared display code. v4->v5 - clean changelog's versioning v3->v4 - split i915 changes from xe (Jani) - apply the rename to the read()'s signature as well (Sashiko) v2->v3 - resolve conflict from rebase v1->v2 - rebase onto drm-tip (Jani) Bspec: 19978 Suggested-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Michał Grzelak <michal.grzelak@intel.com> Link: https://patch.msgid.link/20260828190956.2622350-2-michal.grzelak@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-08-31drm/i915/display: remove unnecessary clock_gating include from intel_display.cLuca Coelho
We don't use any of the functions inclued in intel_clock_gating.h in the intel_display.c code anymore. Remove the respective include. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patch.msgid.link/20260817092911.342072-4-luciano.coelho@intel.com Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2026-08-31drm/i915/display: consolidate remaining clock gating initializationLuca Coelho
The remaining platform-specific display clock gating functions are still called directly by i915. Extend intel_display_init_clock_gating() so that it calls the correct functions for the remaining platforms. This groups Broadwell's three display operations into a single function. This changes the call order slighlty in relation to non-display workarounds, but it shouldn't be a problem. For IVB, we move the trickle-feed programming to the display helper and runs with the other display register setup. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patch.msgid.link/20260817092911.342072-3-luciano.coelho@intel.com Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2026-08-31drm/i915/display: consolidate Gen9 clock gating initializationLuca Coelho
Instead of exporting many of the display clock gating functions, consolidate them into a single function that checks the platform and calls the appropriate platform-specific function. Start consolidating the Gen 9 functions first into a new intel_display_init_clock_gating() function. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patch.msgid.link/20260817092911.342072-2-luciano.coelho@intel.com Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2026-08-31drm/i915: Guard against NULL driver_data in i915_pci_probe()Deepanshu Kartikey
pci_match_device() can return the dummy pci_device_id_any entry when a device is force-bound via sysfs driver_override, in which case ->driver_data is unset (NULL). i915_pci_probe() casts it to struct intel_device_info * unconditionally and dereferences intel_info->require_force_probe, causing a NULL-ptr-deref. Reported-by: syzbot+db96c5ff032f4292a8dc@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=db96c5ff032f4292a8dc Tested-by: syzbot+db96c5ff032f4292a8dc@syzkaller.appspotmail.com Cc: stable@vger.kernel.org Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com> Link: https://patch.msgid.link/20260813064902.367504-1-kartikey406@gmail.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
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/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