aboutsummaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2025-12-19drm/msm: adreno: fix deferencing ifpc_reglist when not declaredNeil Armstrong1-8/+10
On plaforms with an a7xx GPU not supporting IFPC, the ifpc_reglist if still deferenced in a7xx_patch_pwrup_reglist() which causes a kernel crash: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008 ... pc : a6xx_hw_init+0x155c/0x1e4c [msm] lr : a6xx_hw_init+0x9a8/0x1e4c [msm] ... Call trace: a6xx_hw_init+0x155c/0x1e4c [msm] (P) msm_gpu_hw_init+0x58/0x88 [msm] adreno_load_gpu+0x94/0x1fc [msm] msm_open+0xe4/0xf4 [msm] drm_file_alloc+0x1a0/0x2e4 [drm] drm_client_init+0x7c/0x104 [drm] drm_fbdev_client_setup+0x94/0xcf0 [drm_client_lib] drm_client_setup+0xb4/0xd8 [drm_client_lib] msm_drm_kms_post_init+0x2c/0x3c [msm] msm_drm_init+0x1a4/0x228 [msm] msm_drm_bind+0x30/0x3c [msm] ... Check the validity of ifpc_reglist before deferencing the table to setup the register values. Fixes: a6a0157cc68e ("drm/msm/a6xx: Enable IFPC on Adreno X1-85") Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/688944/ Message-ID: <20251117-topic-sm8x50-fix-a6xx-non-ifpc-v1-1-e4473cbf5903@linaro.org> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2025-12-19drm/panic: avoid WARN when checking format supportFrancesco Valla1-1/+1
Use drm_draw_can_convert_from_xrgb8888() instead of drm_draw_color_from_xrgb8888() while checking if a color format is usable. This avoids a WARN in case the first format is not usable. Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Signed-off-by: Francesco Valla <francesco@valla.it> Link: https://patch.msgid.link/20251217-drm_draw_conv_check-v3-3-15b6f8bc1cbc@valla.it Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com>
2025-12-19drm/log: avoid WARN when searching for usable formatFrancesco Valla1-1/+1
Use drm_draw_can_convert_from_xrgb8888() instead of drm_draw_color_from_xrgb8888() while searching for a usable color format. This avoids a WARN in case the first format is not usable. Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Signed-off-by: Francesco Valla <francesco@valla.it> Link: https://patch.msgid.link/20251217-drm_draw_conv_check-v3-2-15b6f8bc1cbc@valla.it Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com>
2025-12-19drm/draw: add drm_draw_can_convert_from_xrgb8888Francesco Valla2-0/+31
Add drm_draw_can_convert_from_xrgb8888() function that can be used to determine if a XRGB8888 color can be converted to the specified format. Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Signed-off-by: Francesco Valla <francesco@valla.it> Link: https://patch.msgid.link/20251217-drm_draw_conv_check-v3-1-15b6f8bc1cbc@valla.it Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com>
2025-12-19drm/xe: Print GuC queue submission state on engine resetMatthew Brost1-2/+3
Print the GuC queue submission state when an engine reset occurs, as this provides clues about the cause of the reset. Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patch.msgid.link/20251218224546.4057424-1-matthew.brost@intel.com
2025-12-19drm/xe: Increase log level for unhandled page faultsMatthew Brost2-24/+24
Set the kernel log level for unhandled page faults to match the log level (info) for engine resets. Currently, dmesg output can be confusing because it shows an engine reset without indicating the page fault that caused it. Without this change, the GuC log must be examined to determine the source of the engine reset. Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Stuart Summers <stuart.summers@intel.com> Link: https://patch.msgid.link/20251218223745.4045207-1-matthew.brost@intel.com
2025-12-19drm/i915/pc8: Add parent interface for PC8 forcewake tricksVille Syrjälä7-4/+68
We use forcewake to prevent the SoC from actually entering PC8 while performing the PC8 disable sequence. Hide that behind a new parent interface to eliminate the naked forcewake/uncore usage from the display power code. v2: Mark the interface optional and warn if someone calls it when not provided (Jani) Include the header to make sure the extern declaration matches the definition (Jani) v3: Rebase due to shuffling Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251218182052.18756-1-ville.syrjala@linux.intel.com
2025-12-19drm/i915/cx0: Toggle powerdown states for C10 on HDMIGustavo Sousa1-0/+15
A new step has been added to Bspec with respect to the C10 PHY, which instructs the driver to toggle powerdown value for boths PHY lanes to P0 and then P2 when driving an HDMI connector. This update in the Bspec reflects the changes required by Wa_14026084006, so document it. Note that, unlike other display workarounds, this one is actually tied to the C10 PHY and not to a specific display IP. As such, let's just document it in intel_cx0_phy.c instead of adding it to intel_display_wa.c. Bspec: 64568, 74489 Reviewed-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com> Link: https://patch.msgid.link/20251216-wa_14026084006-c10-hdmi-toggle-powerdown-v1-2-08677b03e2f1@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2025-12-19drm/i915/cx0: Use a more accurate message for powerdown change failureGustavo Sousa1-1/+1
We do not use the function intel_cx0_powerdown_change_sequence() exclusively to take the PHY out of reset, hence the warning message on failure is misleading. Furthermore, in an upcoming change, we will also use that function to implement a new C10 PHY workaround. Use a more accurate message by saying that we failed to change the powerdown state. Reviewed-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com> Link: https://patch.msgid.link/20251216-wa_14026084006-c10-hdmi-toggle-powerdown-v1-1-08677b03e2f1@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2025-12-19drm/xe/xe_survivability: Add index bound checkRiana Tauro1-3/+7
Fix static analysis tool reported issue. Add index bound check before accessing info array to prevent out of bound. Fixes: f4e9fc967afd ("drm/xe/xe_survivability: Redesign survivability mode") Signed-off-by: Riana Tauro <riana.tauro@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patch.msgid.link/20251219105224.871930-6-riana.tauro@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-12-19drm/xe/xe_survivability: Use static for survivability info attributesRiana Tauro1-9/+9
Fix sparse warnings. Use static for survivability info attributes. Fixes: f4e9fc967afd ("drm/xe/xe_survivability: Redesign survivability mode") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202512101919.G12cuhBJ-lkp@intel.com/ Signed-off-by: Riana Tauro <riana.tauro@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patch.msgid.link/20251219105224.871930-5-riana.tauro@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-12-19drm/xe/pmu: Replace sprintf() with sysfs_emit()Madhur Kumar1-1/+1
Replace sprintf() calls with sysfs_emit() to follow current kernel coding standards. sysfs_emit() is the preferred method for formatting sysfs output as it provides better bounds checking and is more secure. Signed-off-by: Madhur Kumar <madhurkumar004@gmail.com> Link: https://patch.msgid.link/20251214083659.2412218-1-madhurkumar004@gmail.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> [Rodrigo adjusted commit message while pushing it]
2025-12-19drm/i915/dp: Fail state computation for invalid DSC source input BPP valuesImre Deak1-7/+21
There is no reason to accept an invalid minimum/maximum DSC source input BPP value (i.e a minimum DSC input BPP value above the maximum pipe BPP or a maximum DSC input BPP value below the minimum pipe BPP value), fail the state computation in these cases. Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20251215192357.172201-17-imre.deak@intel.com
2025-12-19drm/i915/dp: Fail state computation for invalid max sink compressed BPP valueImre Deak1-2/+1
There is no reason to accept an invalid maximum sink compressed BPP value (i.e. 0), fail the state computation in this case. Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20251215192357.172201-16-imre.deak@intel.com
2025-12-19drm/i915/dp: Fail state computation for invalid max throughput BPP valueImre Deak1-2/+0
There is no reason to accept a minimum/maximum link BPP value above the maximum throughput BPP value, fail the state computation in this case. Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20251215192357.172201-15-imre.deak@intel.com
2025-12-19drm/i915/dp: Fail state computation for invalid min/max link BPP valuesImre Deak1-1/+6
Make sure that state computation fails if the minimum/maximum link BPP values got invalid as a result of limiting both of these values separately to the corresponding source/sink capability limits. Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20251215192357.172201-14-imre.deak@intel.com
2025-12-19drm/i915/dp: Account with pipe joiner max compressed BPP limit for DP-MST ↵Imre Deak1-8/+8
and eDP The pipe joiner maximum compressed BPP must be limited based on the pipe joiner memory size and BW, do that for all DP outputs by adjusting the max compressed BPP value already in intel_dp_compute_config_link_bpp_limits() (which is used by all output types). This way the BPP doesn't need to be adjusted in dsc_compute_compressed_bpp() (called for DP-SST after the above limits were computed already), so remove the adjustment from there. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20251215192357.172201-13-imre.deak@intel.com
2025-12-19drm/i915/dp: Account with DSC BW overhead for compressed DP-SST stream BWImre Deak1-1/+5
A DSC compressed stream requires FEC (except for eDP), which has a BW overhead on non-UHBR links that must be accounted for explicitly. Do that during computing the required BW. Note that the overhead doesn't need to be accounted for on UHBR links where FEC is always enabled and so the corresponding overhead is part of the channel coding efficiency instead (i.e. the overhead is part of the available vs. the required BW). Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20251215192357.172201-12-imre.deak@intel.com
2025-12-19drm/i915/dp: Account with MST, SSC BW overhead for uncompressed DP-MST stream BWImre Deak1-1/+4
On MST links the symbol alignment and SSC have a BW overhead, which should be accounted for when calculating the required stream BW, do so during mode validation for an uncompressed stream. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20251215192357.172201-11-imre.deak@intel.com
2025-12-19drm/i915/dp: Use the effective data rate for DP compressed BW calculationImre Deak1-11/+16
Use intel_dp_effective_data_rate() to calculate the required link BW for compressed streams on non-UHBR DP-SST links. This ensures that the BW is calculated the same way for all DP output types and DSC/non-DSC modes, during mode validation as well as during state computation. This approach also allows for accounting with BW overhead due to DSC, FEC being enabled on a link. Acounting for these will be added by follow-up changes. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20251215192357.172201-10-imre.deak@intel.com
2025-12-19drm/i915/dp: Use the effective data rate for DP BW calculationImre Deak4-19/+33
Use intel_dp_effective_data_rate() to calculate the required link BW for eDP, DP-SST and MST links. This ensures that the BW is calculated the same way for all DP output types, during mode validation as well as during state computation. This approach also allows for accounting with BW overheads due to the SSC, DSC, FEC being enabled on a link, as well as due to the MST symbol alignment on the link. Accounting for these overheads will be added by follow-up changes. This way also computes the stream BW on a UHBR link correctly, using the corresponding symbol size to effective data size ratio (i.e. ~97% link BW utilization for UHBR vs. only ~80% for non-UHBR). Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20251215192357.172201-9-imre.deak@intel.com
2025-12-19drm/i915/dp: Fix BW check in is_bw_sufficient_for_dsc_config()Imre Deak1-1/+1
is_bw_sufficient_for_dsc_config() should return true if the required BW equals the available BW, make it so. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20251215192357.172201-8-imre.deak@intel.com
2025-12-19drm/i915/dp: Factor out intel_dp_link_bw_overhead()Imre Deak3-16/+34
Factor out intel_dp_link_bw_overhead(), used later for BW calculation during DP SST mode validation and state computation. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20251215192357.172201-7-imre.deak@intel.com
2025-12-19drm/i915/dp: Use a mode's crtc_clock vs. clock during state computationImre Deak1-2/+3
The encoder state computation should use the drm_display_mode::crtc_clock member, instead of the clock member, the former one possibly having a necessary adjustment wrt. to the latter due to driver specific constraints. In practice the two values should not differ at spots changed in this patch, since only MSO and 3D modes would make them different, neither MSO or 3D relevant here, but still use the expected crtc_clock version for consistency. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20251215192357.172201-6-imre.deak@intel.com
2025-12-19drm/i915/dp: Return a fixed point BPP value from intel_dp_output_bpp()Imre Deak3-22/+26
Convert intel_dp_output_bpp() and intel_dp_mode_min_output_bpp() to return an x16 fixed point bpp value, as this value will be always the link BPP (either compressed or uncompressed) tracked in the same x16 fixed point format. While at it rename intel_dp_output_bpp() to intel_dp_output_format_link_bpp_x16() and intel_dp_mode_min_output_bpp() to intel_dp_mode_min_link_bpp_x16() to better reflect that these functions return an x16 link BPP value specific to a particular output format or mode. Also rename intel_dp_output_bpp()'s bpp parameter to pipe_bpp, to clarify which kind of (pipe vs. link) BPP the parameter is. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20251215192357.172201-5-imre.deak@intel.com
2025-12-19drm/i915/dp: Fix DSC sink's slice count capability checkImre Deak1-5/+13
A DSC sink supporting DSC slice count N, not necessarily supports slice counts less than N. Hence the driver should check the sink's support for a particular slice count before using that slice count, fix intel_dp_dsc_get_slice_count() accordingly. Cc: dri-devel@lists.freedesktop.org Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20251215192357.172201-4-imre.deak@intel.com
2025-12-19drm/dp: Add drm_dp_dsc_sink_slice_count_mask()Imre Deak1-24/+58
A DSC sink supporting DSC slice count N, not necessarily supports slice counts less than N. Hence the driver should check the sink's support for a particular slice count before using that slice count. Add the helper functions required for this. Cc: dri-devel@lists.freedesktop.org Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20251215192357.172201-3-imre.deak@intel.com
2025-12-19drm/dp: Parse all DSC slice count caps for eDP 1.5Imre Deak1-23/+18
eDP 1.5 supports all the slice counts reported via DP_DSC_SLICE_CAP_1, so adjust drm_dp_dsc_sink_max_slice_count() accordingly. Cc: dri-devel@lists.freedesktop.org Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20251215192357.172201-2-imre.deak@intel.com
2025-12-19drm/panthor: Support partial unmaps of huge pagesAdrián Larumbe1-8/+92
Commit 33729a5fc0ca ("iommu/io-pgtable-arm: Remove split on unmap behavior") did away with the treatment of partial unmaps of huge IOPTEs. In the case of Panthor, that means an attempt to run a VM_BIND unmap operation on a memory region whose start address and size aren't 2MiB aligned, in the event it intersects with a huge page, would lead to ARM IOMMU management code to fail and a warning being raised. Presently, and for lack of a better alternative, it's best to have Panthor handle partial unmaps at the driver level, by unmapping entire huge pages and remapping the difference between them and the requested unmap region. This could change in the future when the VM_BIND uAPI is expanded to enforce huge page alignment and map/unmap operational constraints that render this code unnecessary. When a partial unmap for a huge PTE is attempted, we also need to expand the locked region to encompass whole huge pages. Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Steven Price <steven.price@arm.com> Link: https://patch.msgid.link/20251217213252.677020-2-adrian.larumbe@collabora.com Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
2025-12-19drm/panthor: Evict groups before VM terminationKetil Johnsen3-0/+19
Ensure all related groups are evicted and suspended before VM destruction takes place. This fixes an issue where panthor_vm_destroy() destroys and unmaps the heap context while there are still on slot groups using this. The FW will do a write out to the heap context when a CSG (group) is suspended, so a premature unmap of the heap context will cause a GPU page fault. This page fault is quite harmless, and do not affect the continued operation of the GPU. Fixes: 647810ec2476 ("drm/panthor: Add the MMU/VM logical block") Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by: Ketil Johnsen <ketil.johnsen@arm.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Reviewed-by: Steven Price <steven.price@arm.com> Link: https://patch.msgid.link/20251219093546.1227697-1-ketil.johnsen@arm.com Co-developed-by: Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
2025-12-19Merge drm/drm-next into drm-xe-nextThomas Hellström81-643/+1650
Backmerging to bring in 6.19-rc1. An important upstream bugfix and to help unblock PTL CI. Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2025-12-19drm/i915/colorop: do not include headers from headersJani Nikula2-1/+5
drm_colorop.h doesn't need the intel_display_types.h include for anything. Don't include headers from headers if it can be avoided. Fixes: 3e9b06559aa1 ("drm/i915: Add intel_color_op") Cc: Suraj Kandpal <suraj.kandpal@intel.com> Cc: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Cc: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Link: https://patch.msgid.link/20251218141807.409751-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-12-19drm/i915/dp: Restrict max source rate for WCL to HBR3Ankit Nautiyal1-1/+2
WCL supports a maximum of HBR3 8.1 Gbps for both eDP/DP. Limit the max source rate to HBR3 for WCL. v2: Move the check inside mtl_max_source_rate(). (Suraj) Bspec:74286 Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20251122053651.759389-1-ankit.k.nautiyal@intel.com
2025-12-19Merge tag 'drm-xe-fixes-2025-12-19' of ↵Dave Airlie19-46/+75
https://gitlab.freedesktop.org/drm/xe/kernel into drm-fixes UAPI Changes: - Limit num_syncs to prevent oversized kernel allocations (Shuicheng) - Disallow 0 OA property values (Ashutosh) - Disallow 0 EU stall property values (Ashutosh) Driver Changes: - Fix kobject leak (Shuicheng) - Workaround (Vinay) - Loop variable reference fix (Matt Brost) - Fix a CONFIG corner-case incorrect number of arguments (Arnd Bergmann) - Skip reason prefix while emitting array (Raag) - VF migration fix (Tomasz) - Fix context in mei interrupt top half (Junxiao) - Don't include the CCS metadata in the dma-buf sg-table (Thomas) - VF queueing recovery work fix (Satyanarayana) - Increase TDF timeout (Jagmeet) - GT reset registers vs scheduler ordering fix (Jan) - Adjust long-running workload timeslices (Matt Brost) - Always set OA_OAGLBCTXCTRL_COUNTER_RESUME (Ashutosh) - Fix a return value (Dan Carpenter) - Drop preempt-fences when destroying imported dma-bufs (Thomas) - Use usleep_range for accurate long-running workload timeslicing (Matthew) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Thomas Hellstrom <thomas.hellstrom@linux.intel.com> Link: https://patch.msgid.link/aUSMlQ4iruzm0NQR@fedora
2025-12-18drm/xe: Fix documentation heading levels in xe_guc_pc.cSwaraj Gaikwad1-2/+2
Sphinx reports htmldocs warnings: Documentation/gpu/xe/xe_firmware:31: ./drivers/gpu/drm/xe/xe_guc_pc.c:76: ERROR: A level 2 section cannot be used here. Documentation/gpu/xe/xe_firmware:31: ./drivers/gpu/drm/xe/xe_guc_pc.c:87: ERROR: A level 2 section cannot be used here. The xe_guc_pc.c documentation is included inside xe_firmware.rst. The headers in the C file currently use '=' underlines, which conflict with the parent document's section levels. Fix this by demoting "Frequency management" and "Render-C States" headers from '=' to '-' to correctly nest them as subsections. Build environment: Python 3.13.7 Sphinx 8.2.3 docutils 0.22.3 Signed-off-by: Swaraj Gaikwad <swarajgaikwad1925@gmail.com> Link: https://patch.msgid.link/20251209094836.18589-1-swarajgaikwad1925@gmail.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-12-18drm/xe/xe_survivability: Remove unused indexRiana Tauro1-11/+4
Remove unused index variable and fix for loop. Fixes: f4e9fc967afd ("drm/xe/xe_survivability: Redesign survivability mode") Reported-by: Nathan Chancellor <nathan@kernel.org> Closes: https://lore.kernel.org/intel-xe/20251210075757.GA1206705@ax162/ Signed-off-by: Riana Tauro <riana.tauro@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patch.msgid.link/20251218105151.586575-5-riana.tauro@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-12-19Merge tag 'drm-misc-fixes-2025-12-18' of ↵Dave Airlie5-7/+187
https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes drm-misc-fixes for v6.19-rc2: - Add -EDEADLK handling in drm unit tests. - Plug DRM_IOCTL_GEM_CHANGE_HANDLE leak. - Fix regression in sony-td4353-jdi. - Kconfig fix for visionox-rm69299. - Do not load amdxdna when running virtualized. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patch.msgid.link/21861d1b-54bf-4853-9c35-97abe3c5deba@linux.intel.com
2025-12-18drm/xe/nvm: enable cri platformAlexander Usyskin2-11/+24
Mark CRI as one that have the CSC NVM device. Update the writable override flow to take the information from the scratch register for CRI. Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patch.msgid.link/20251216111034.3093507-1-alexander.usyskin@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-12-18drm/xe: Use usleep_range for accurate long-running workload timeslicingMatthew Brost1-1/+19
msleep is not very accurate in terms of how long it actually sleeps, whereas usleep_range is precise. Replace the timeslice sleep for long-running workloads with the more accurate usleep_range to avoid jitter if the sleep period is less than 20ms. Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Cc: stable@vger.kernel.org Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Link: https://patch.msgid.link/20251212182847.1683222-3-matthew.brost@intel.com (cherry picked from commit ca415c4d4c17ad676a2c8981e1fcc432221dce79) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2025-12-18drm/xe: Drop preempt-fences when destroying imported dma-bufs.Thomas Hellström1-11/+4
When imported dma-bufs are destroyed, TTM is not fully individualizing the dma-resv, but it *is* copying the fences that need to be waited for before declaring idle. So in the case where the bo->resv != bo->_resv we can still drop the preempt-fences, but make sure we do that on bo->_resv which contains the fence-pointer copy. In the case where the copying fails, bo->_resv will typically not contain any fences pointers at all, so there will be nothing to drop. In that case, TTM would have ensured all fences that would have been copied are signaled, including any remaining preempt fences. Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Fixes: fa0af721bd1f ("drm/ttm: test private resv obj on release/destroy") Cc: Matthew Brost <matthew.brost@intel.com> Cc: <stable@vger.kernel.org> # v6.16+ Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Tested-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20251217093441.5073-1-thomas.hellstrom@linux.intel.com (cherry picked from commit 425fe550fb513b567bd6d01f397d274092a9c274) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2025-12-18drm/xe/eustall: Disallow 0 EU stall property valuesAshutosh Dixit1-1/+1
An EU stall property value of 0 is invalid and will cause a NPD. Reported-by: Peter Senna Tschudin <peter.senna@linux.intel.com> Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/6453 Fixes: 1537ec85ebd7 ("drm/xe/uapi: Introduce API for EU stall sampling") Cc: stable@vger.kernel.org Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Reviewed-by: Harish Chegondi <harish.chegondi@intel.com> Link: https://patch.msgid.link/20251212061850.1565459-4-ashutosh.dixit@intel.com (cherry picked from commit 5bf763e908bf795da4ad538d21c1ec41f8021f76) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2025-12-18drm/xe/oa: Disallow 0 OA property valuesAshutosh Dixit1-1/+1
An OA property value of 0 is invalid and will cause a NPD. Reported-by: Peter Senna Tschudin <peter.senna@linux.intel.com> Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/6452 Fixes: cc4e6994d5a2 ("drm/xe/oa: Move functions up so they can be reused for config ioctl") Cc: stable@vger.kernel.org Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Reviewed-by: Harish Chegondi <harish.chegondi@intel.com> Link: https://patch.msgid.link/20251212061850.1565459-3-ashutosh.dixit@intel.com (cherry picked from commit 7a100e6ddcc47c1f6ba7a19402de86ce24790621) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2025-12-18drm/xe/xe_sriov_vfio: Fix return value in xe_sriov_vfio_migration_supported()Dan Carpenter1-1/+1
The xe_sriov_vfio_migration_supported() function is type bool so returning -EPERM means returning true. Return false instead. Fixes: bd45d46ffc8f ("drm/xe/pf: Export helpers for VFIO") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patch.msgid.link/aTLEZ4g-FD-iMQ2V@stanley.mountain Signed-off-by: Michał Winiarski <michal.winiarski@intel.com> (cherry picked from commit 0a2404c8f6a3a120f79c57ef8a3302c8e8bc34d9) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2025-12-18drm/xe/oa: Always set OAG_OAGLBCTXCTRL_COUNTER_RESUMEAshutosh Dixit1-3/+4
Reports can be written out to the OA buffer using ways other than periodic sampling. These include mmio trigger and context switches. To support these use cases, when periodic sampling is not enabled, OAG_OAGLBCTXCTRL_COUNTER_RESUME must be set. Fixes: 1db9a9dc90ae ("drm/xe/oa: OA stream initialization (OAG)") Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Reviewed-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Link: https://patch.msgid.link/20251205212613.826224-4-ashutosh.dixit@intel.com (cherry picked from commit 88d98e74adf3e20f678bb89581a5c3149fdbdeaa) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2025-12-18drm/xe: Adjust long-running workload timeslices to reasonable valuesMatthew Brost2-2/+5
A 10ms timeslice for long-running workloads is far too long and causes significant jitter in benchmarks when the system is shared. Adjust the value to 5ms for preempt-fencing VMs, as the resume step there is quite costly as memory is moved around, and set it to zero for pagefault VMs, since switching back to pagefault mode after dma-fence mode is relatively fast. Also change min_run_period_ms to 'unsiged int' type rather than 's64' as only positive values make sense. Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Cc: stable@vger.kernel.org Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Link: https://patch.msgid.link/20251212182847.1683222-2-matthew.brost@intel.com (cherry picked from commit 33a5abd9a68394aa67f9618b20eee65ee8702ff4) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2025-12-18drm/xe/oa: Limit num_syncs to prevent oversized allocationsShuicheng Lin1-0/+3
The OA open parameters did not validate num_syncs, allowing userspace to pass arbitrarily large values, potentially leading to excessive allocations. Add check to ensure that num_syncs does not exceed DRM_XE_MAX_SYNCS, returning -EINVAL when the limit is violated. v2: use XE_IOCTL_DBG() and drop duplicated check. (Ashutosh) Fixes: c8507a25cebd ("drm/xe/oa/uapi: Define and parse OA sync properties") Cc: Matthew Brost <matthew.brost@intel.com> Cc: Ashutosh Dixit <ashutosh.dixit@intel.com> Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com> Reviewed-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20251205234715.2476561-6-shuicheng.lin@intel.com (cherry picked from commit e057b2d2b8d815df3858a87dffafa2af37e5945b) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2025-12-18drm/xe: Limit num_syncs to prevent oversized allocationsShuicheng Lin2-1/+5
The exec and vm_bind ioctl allow userspace to specify an arbitrary num_syncs value. Without bounds checking, a very large num_syncs can force an excessively large allocation, leading to kernel warnings from the page allocator as below. Introduce DRM_XE_MAX_SYNCS (set to 1024) and reject any request exceeding this limit. " ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1217 at mm/page_alloc.c:5124 __alloc_frozen_pages_noprof+0x2f8/0x2180 mm/page_alloc.c:5124 ... Call Trace: <TASK> alloc_pages_mpol+0xe4/0x330 mm/mempolicy.c:2416 ___kmalloc_large_node+0xd8/0x110 mm/slub.c:4317 __kmalloc_large_node_noprof+0x18/0xe0 mm/slub.c:4348 __do_kmalloc_node mm/slub.c:4364 [inline] __kmalloc_noprof+0x3d4/0x4b0 mm/slub.c:4388 kmalloc_noprof include/linux/slab.h:909 [inline] kmalloc_array_noprof include/linux/slab.h:948 [inline] xe_exec_ioctl+0xa47/0x1e70 drivers/gpu/drm/xe/xe_exec.c:158 drm_ioctl_kernel+0x1f1/0x3e0 drivers/gpu/drm/drm_ioctl.c:797 drm_ioctl+0x5e7/0xc50 drivers/gpu/drm/drm_ioctl.c:894 xe_drm_ioctl+0x10b/0x170 drivers/gpu/drm/xe/xe_device.c:224 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:598 [inline] __se_sys_ioctl fs/ioctl.c:584 [inline] __x64_sys_ioctl+0x18b/0x210 fs/ioctl.c:584 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xbb/0x380 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f ... " v2: Add "Reported-by" and Cc stable kernels. v3: Change XE_MAX_SYNCS from 64 to 1024. (Matt & Ashutosh) v4: s/XE_MAX_SYNCS/DRM_XE_MAX_SYNCS/ (Matt) v5: Do the check at the top of the exec func. (Matt) Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Reported-by: Koen Koning <koen.koning@intel.com> Reported-by: Peter Senna Tschudin <peter.senna@linux.intel.com> Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/6450 Cc: <stable@vger.kernel.org> # v6.12+ Cc: Matthew Brost <matthew.brost@intel.com> Cc: Michal Mrozek <michal.mrozek@intel.com> Cc: Carl Zhang <carl.zhang@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Cc: Ivan Briano <ivan.briano@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Ashutosh Dixit <ashutosh.dixit@intel.com> Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20251205234715.2476561-5-shuicheng.lin@intel.com (cherry picked from commit b07bac9bd708ec468cd1b8a5fe70ae2ac9b0a11c) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2025-12-18drm/xe: Drop preempt-fences when destroying imported dma-bufs.Thomas Hellström1-11/+4
When imported dma-bufs are destroyed, TTM is not fully individualizing the dma-resv, but it *is* copying the fences that need to be waited for before declaring idle. So in the case where the bo->resv != bo->_resv we can still drop the preempt-fences, but make sure we do that on bo->_resv which contains the fence-pointer copy. In the case where the copying fails, bo->_resv will typically not contain any fences pointers at all, so there will be nothing to drop. In that case, TTM would have ensured all fences that would have been copied are signaled, including any remaining preempt fences. Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Fixes: fa0af721bd1f ("drm/ttm: test private resv obj on release/destroy") Cc: Matthew Brost <matthew.brost@intel.com> Cc: <stable@vger.kernel.org> # v6.16+ Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Tested-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20251217093441.5073-1-thomas.hellstrom@linux.intel.com
2025-12-18drm/imagination: Disallow exporting of PM/FW protected objectsAlessio Belle1-0/+11
These objects are meant to be used by the GPU firmware or by the PM unit within the GPU, in which case they may contain physical addresses. This adds a layer of protection against exposing potentially exploitable information outside of the driver. Fixes: ff5f643de0bf ("drm/imagination: Add GEM and VM related code") Signed-off-by: Alessio Belle <alessio.belle@imgtec.com> Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20251208-no-export-pm-fw-obj-v1-1-83ab12c61693@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2025-12-18drm/gem: Fix kerneldoc warningsLoïc Molinari1-2/+5
Fix incorrect parameters in drm_gem_shmem_init() and missing " *" on empty lines in drm_gem_get_huge_mnt(). Signed-off-by: Loïc Molinari <loic.molinari@collabora.com> Fixes: 6e0b1b82017b ("drm/gem: Add huge tmpfs mountpoint helpers") Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Closes: https://lore.kernel.org/dri-devel/20251216115605.4babbce0@canb.auug.org.au/ Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Randy Dunlap <rdunlap@infradead.org> Tested-by: Randy Dunlap <rdunlap@infradead.org> Link: https://patch.msgid.link/20251217172404.31216-1-loic.molinari@collabora.com Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>