summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm
AgeCommit message (Collapse)Author
2025-10-31Merge tag 'amd-drm-fixes-6.18-2025-10-29' of ↵Simona Vetter
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes amd-drm-fixes-6.18-2025-10-29: amdgpu: - VPE idle handler fix - Re-enable DM idle optimizations - DCN3.0 fix - SMU fix - Powerplay fixes for fiji/iceland - License fixes - HDP eDP panel fix - Vblank fix radeon: - devm migration fixes Signed-off-by: Simona Vetter <simona.vetter@ffwll.ch> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patch.msgid.link/20251029201342.8813-1-alexander.deucher@amd.com
2025-10-31Merge tag 'drm-intel-gt-next-2025-10-29' of ↵Simona Vetter
https://gitlab.freedesktop.org/drm/i915/kernel into drm-next Driver Changes: Fixes/improvements/new stuff: - Set O_LARGEFILE in __create_shmem() (Taotao Chen) - Fix incorrect error handling in shmem_pwrite() (Taotao Chen) - Skip GuC communication warning on reset in progress [guc] (Zhanjun Dong) - Fix conversion between clock ticks and nanoseconds [guc] (Umesh Nerlige Ramappa) Miscellaneous: - Avoid accessing uninitialized context in emit_rpcs_query() [selftests] (Krzysztof Karas) - Fix typo in comment (I915_EXEC_NO_RELOC) [gem] (Marlon Henrique Sanches) Backmerges: - Merge drm/drm-next into drm-intel-gt-next (Joonas Lahtinen) Signed-off-by: Simona Vetter <simona.vetter@ffwll.ch> From: Tvrtko Ursulin <tursulin@igalia.com> Link: https://patch.msgid.link/aQH994lQI_iVPzTI@linux
2025-10-31Merge tag 'mediatek-drm-fixes-20251028' of ↵Simona Vetter
https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux into drm-fixes Mediatek DRM Fixes - 20251028 1. Fix device use-after-free on unbind Signed-off-by: Simona Vetter <simona.vetter@ffwll.ch> From: Chun-Kuang Hu <chunkuang.hu@kernel.org> Link: https://patch.msgid.link/20251028151548.3944-1-chunkuang.hu@kernel.org
2025-10-31Merge tag 'drm-misc-next-2025-10-28' of ↵Simona Vetter
https://gitlab.freedesktop.org/drm/misc/kernel into drm-next drm-misc-next for v6.19-rc1: UAPI Changes: Cross-subsystem Changes: - Update DT bindings for renesas and powervr-rogue. - Update MAINTAINERS email and add spsc_queue. Core Changes: - Allow ttm page protection flags on risc-v. - Move freeing of drm client memory to driver. Driver Changes: - Assorted small fixes and updates to qaic, ivpu, st7571-i2c, gud, amdxdna. - Allow configuration of vkms' display through configfs. - Add Arm Ethos-U65/U85 accel driver. Signed-off-by: Simona Vetter <simona.vetter@ffwll.ch> From: Maarten Lankhorst <dev@lankhorst.se> Link: https://patch.msgid.link/32b43261-3c99-49d9-92ee-615ada1d01e8@lankhorst.se
2025-10-31Merge tag 'drm-xe-next-2025-10-28' of ↵Simona Vetter
https://gitlab.freedesktop.org/drm/xe/kernel into drm-next Driver Changes: More xe3p support (Harish, Brian, Balasubramani, Matt Roper) Make panic support work on VRAM for display (Maarten) Fix stolen size check (Shuicheng) xe_pci_test update (Gustavo) VF migration updates (Tomasz) A couple of fixes around allocation and PM references (Matt Brost) Migration update for the MEM_COPY instruction (Matt Auld) Initial CRI support (Balasubramani, Matt Roper) Use SVM range helpers in PT layer (Matt Brost) Drop MAX_GT_TYPE_CHARS constant (Matt Roper) Fix spelling and typos (Sanjay) Fix VF FLR synchronization between all GTs (Michal) Add a Workaround (Nitin) Access VF's register using dedicated MMIO view (Michal) Signed-off-by: Simona Vetter <simona.vetter@ffwll.ch> From: Thomas Hellstrom <thomas.hellstrom@linux.intel.com> Link: https://patch.msgid.link/aQCl9uJxN6CWJ8Vg@fedora
2025-10-31Merge tag 'amd-drm-next-6.19-2025-10-24' of ↵Simona Vetter
https://gitlab.freedesktop.org/agd5f/linux into drm-next amd-drm-next-6.19-2025-10-24: amdgpu: - HMM cleanup - Add new RAS framework - DML2.1 updates - YCbCr420 fixes - DC FP fixes - DMUB fixes - LTTPR fixes - DTBCLK fixes - DMU cursor offload handling - Userq validation improvements - Misc code cleanups - Unify shutdown callback handling - Suspend improvements - Power limit code cleanup - Fence cleanup - IP Discovery cleanup - SR-IOV fixes - AUX backlight fixes - DCN 3.5 fixes - HDMI compliance fixes - DCN 4.0.1 cursor updates - DCN interrupt fix - DC KMS full update improvements - Add additional HDCP traces - DCN 3.2 fixes - DP MST fixes - Add support for new SR-IOV mailbox interface Signed-off-by: Simona Vetter <simona.vetter@ffwll.ch> From: Alex Deucher <alexander.deucher@amd.com> Link: https://lore.kernel.org/r/20251024175249.58099-1-alexander.deucher@amd.com
2025-10-31drm/xe/xe3: Extend wa_14023061436Tangudu Tilak Tirumalesh
Extend wa_14023061436 to Graphics Versions 30.03, 30.04 and 30.05. Signed-off-by: Tangudu Tilak Tirumalesh <tilak.tirumalesh.tangudu@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patch.msgid.link/20251030154626.3124565-1-tilak.tirumalesh.tangudu@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2025-10-31drm/xe: highlight reserved PAT entries in dump outputXin Wang
Enhance the PAT table dump by marking reserved entries with an asterisk (*) for improved readability and debugging. V2: Added a note in the "PAT table" header explaining the meaning of the asterisk(*) to improve clarity for readers. (Matt Roper) V3: Introduced a valid field in struct xe_pat_table_entry to explicitly track whether an entry is valid or reserved, avoiding reliance on coh_mode == 0. (Matt Roper) Signed-off-by: Xin Wang <x.wang@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patch.msgid.link/20251030221734.1058350-1-x.wang@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2025-10-31drm/tidss: Set vblank (event) time at crtc_atomic_enableTomi Valkeinen
It was reported that Weston stops at an assert, which checks that the page flip event timestamp is the same or newer than the previous timestamp: weston_output_finish_frame: Assertion `timespec_sub_to_nsec(stamp, &output->frame_time) >= 0' failed. With manual tests, I can see that when I enable the CRTC, I get a page flip event with a timestamp of 0. Tracking this down led to drm_reset_vblank_timestamp() which does "t_vblank = 0" if "high-precision query" is not available. TI DSS does not have any hardware timestamping, and thus the default ktime_get() is used in the DRM framework to get the vblank timestamp, and ktime_get() is not "high precision" here. It is not quite clear why the framework behaves this way, but I assume the idea is that drm_crtc_vblank_on(), which calls drm_reset_vblank_timestamp(), can be called at any time, and thus ktime_get() wouldn't give a good timestamp. And, the idea is that the driver would wait until next vblank after the CRTC enable, and then we could get a good timestamp. This is hinted in the comment: "reinitialize delayed at next vblank interrupt and assign 0 for now". I think that makes sense. However, when we enable the CRTC in TI DSS, i.e. we write the enable bit to the hardware, that's the exact moment when the "vblank cycle" starts. It is the zero point in the cycle, and thus ktime_get() would give a good timestamp. I am not sure if this is applicable to other hardware, and if so, how should it be solved in the framework. So, let's fix this in the tidss driver at least for now. This patch updates the vblank->time manually to ktime_get() just before sending the vblank event, and we enable the crtc just before calling ktime_get(). To get even more exact timing, the dispc_vp_enable() is moved inside the event_lock spinlock. With this, we get a proper timestamp for the page flip event from enabling the CRTC, and Weston is happy. Reviewed-by: Devarsh Thakkar <devarsht@ti.com> Link: https://patch.msgid.link/20250905-tidss-fix-timestamp-v1-2-c2aedf31e2c9@ideasonboard.com Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Closes: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1553964/processor-sdk-am62x-weston-fails-to-wake-from-idle-time-sleep-restarts-after-sigterm Closes: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1416342/am625-am625-doesn-t-wake-up-from-standy-when-idle-time-is-configured-in-weston-ini
2025-10-31drm/tidss: Restructure dispc_vp_prepare() and dispc_vp_enable()Tomi Valkeinen
tidss_crtc.c calls dispc_vp_prepare() and dispc_vp_enable() in that order, next to each other. dispc_vp_prepare() does preparations for enabling the crtc, by writing some registers, and dispc_vp_enable() does more preparations. As the last thing, dispc_vp_enable() enables the CRTC by writing the enable bit. There might have been a reason at some point in the history for this split, but I can't find any point to it. They also do a bit of overlapping work: both call dispc_vp_find_bus_fmt(). They could as well be a single function. But instead of combining them, this patch moves everything from dispc_vp_enable() to dispc_vp_prepare(), except the actual CRTC enable bit write. The reason for this is that unlike all the preparatory register writes, CRTC enable has an immediate effect, starting the timing generator and the CRTC as a whole. Thus it may be important to time the enable just right (as we do in the next patch). No functional changes. Reviewed-by: Devarsh Thakkar <devarsht@ti.com> Link: https://patch.msgid.link/20250905-tidss-fix-timestamp-v1-1-c2aedf31e2c9@ideasonboard.com Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
2025-10-31drm/sched: Add warning for removing hack in drm_sched_fini()Philipp Stanner
The assembled developers agreed at the X.Org Developers Conference 2025 that the hack added for amdgpu in drm_sched_fini() shall be removed. It shouldn't be needed by amdgpu anymore. As it's unclear whether all drivers really follow the life time rule of entities having to be torn down before their scheduler, it is reasonable to warn for a while before removing the hack. Add a warning in drm_sched_fini() that fires if an entity is still active. Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> Signed-off-by: Philipp Stanner <phasta@kernel.org> Link: https://patch.msgid.link/20251023123429.139848-2-phasta@kernel.org
2025-10-31drm/imagination: Fix reference to devm_platform_get_and_ioremap_resource()Geert Uytterhoeven
The call to devm_platform_ioremap_resource() was replaced by a call to devm_platform_get_and_ioremap_resource(), but the comment referring to the function's possible returned error codes was not updated. Fixes: 927f3e0253c11276 ("drm/imagination: Implement MIPS firmware processor and MMU support") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Matt Coster <matt.coster@imgtec.com> Link: https://patch.msgid.link/2266514318480d17f52c7e5e67578dae6827914e.1761745586.git.geert+renesas@glider.be Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2025-10-31drm/i915/xe3p_lpd: use pixel normalizer for fp16 formats for FBCVinod Govindapillai
There is a hw restriction that we could enable the FBC for FP16 formats only if the pixel normalization block is enabled. Hence enable the pixel normalizer block with normalzation factor as 1.0 for the supported FP16 formats to get the FBC enabled. Two existing helper function definitions are moved up to avoid the forward declarations as part of this patch as well. v2: sw/hw state differentiation on handling pixel normalizer (Jani) Bspec: 69863, 68881 Cc: Shekhar Chauhan <shekhar.chauhan@intel.com> Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Link: https://patch.msgid.link/20251027134001.325064-5-vinod.govindapillai@intel.com
2025-10-31drm/i915/xe3p_lpd: extract pixel format valid routine for FP16 formatsVinod Govindapillai
As the pixel normalizer block is needed only for the FP16 formats, separating out the FP16 formats handling will benefit in selectively enabling the pixel normalizer block in the following patch. Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Link: https://patch.msgid.link/20251027134001.325064-4-vinod.govindapillai@intel.com
2025-10-31drm/i915/xe3p_lpd: Add FBC support for FP16 formatsVinod Govindapillai
Add supported FP16 formats for FBC. FBC can be enabled with FP16 formats only when plane pixel normalizer block is enabled. The follow up patches will handle the pixel normalizer block configuration. v2: changes related to comments to use better tracking of pixel normalizer Bspec: 6881, 69863, 68904 Cc: Shekhar Chauhan <shekhar.chauhan@intel.com> Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Link: https://patch.msgid.link/20251027134001.325064-3-vinod.govindapillai@intel.com
2025-10-31drm/i915/xe3p_lpd: Extend FBC support to UINT16 formatsSai Teja Pottumuttu
Starting Xe3p_LPD, FBC is supported on UINT16 formats as well. Also UINT16 being a 64bpp format, will use cpp of 8 for cfb stride and thus size calculations. v2: simplify getting the cpp per format (Ville) simplify the pixel format is valid for xe3p_lp (Vinod) Cc: Shekhar Chauhan <shekhar.chauhan@intel.com> BSpec: 68881, 68904, 69560 Signed-off-by: Sai Teja Pottumuttu <sai.teja.pottumuttu@intel.com> Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Link: https://patch.msgid.link/20251027134001.325064-2-vinod.govindapillai@intel.com
2025-10-31drm/xe/compat: reduce i915_utils.[ch]Jani Nikula
Reduce the compat i915_utils.h to only cover the requirements of MISSING_CASE() in soc/ and the few i915_inject_probe_failure() instances, instead of including the entire i915_utils.h from i915. This prevents new users for the utilities from cropping up. With this, we can remove the xe/display/ext/i915_utils.c altogether. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Link: https://patch.msgid.link/c02f82e45f31caf95bd1339080b9099c3b7190be.1761146196.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-10-31drm/i915/display: switch to intel_display_utils.hJani Nikula
The remaining utils display needs from i915_utils.h are primarily MISSING_CASE() and fetch_and_zero(), with a couple of i915_inject_probe_failure() uses. To avoid excessive churn, add duplicates of MISSING_CASE() and fetch_and_zero() to intel_display_utils.h, and switch display to use the display utils. As long as there are display files that include i915_drv.h, which includes i915_utils.h, we'll need #ifndef guards for MISSING_CASE() and fetch_and_zero() in both utils headers. We can remove them once display no longer depends on i915_drv.h. A couple of files in display still need i915_utils.h for i915_inject_probe_failure(). Annotate this. They will be handled separately. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Link: https://patch.msgid.link/79f9e31ca64c8c045834d48e20ceb0c515d1e9e1.1761146196.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-10-31drm/i915/display: add intel_display_vtd_active()Jani Nikula
Add intel_display_vtd_active() to utils. It's intentional duplication with i915_utils.h i915_vtd_active(), but reduces duplication with xe. Win some, lose some. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Link: https://patch.msgid.link/e022166af7c67f43904e2d0fc87bc5c13e0f1204.1761146196.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-10-31drm/i915/display: add intel_display_run_as_guest()Jani Nikula
Add intel_display_utils.c for display utilities that need more than a header. Start off with intel_display_run_as_guest(). The implementation is intentional duplication of the i915_utils.h i915_run_as_guest(), with the idea that it's small enough to not matter. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Link: https://patch.msgid.link/469f9c41e0c3e3099314a3cf1a7671bf36ec8ffd.1761146196.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-10-31drm/i915/display: create intel_display_utils.hJani Nikula
Start a file for display specific generic utilities. Move KHz() and MHz() helpers there first. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Link: https://patch.msgid.link/dbdd1915466850293b9737b751170dd225197873.1761146196.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-10-31drm/i915: split out separate files for jiffies timeout and wait helpersJani Nikula
Add i915_jiffies.h and intel_display_jiffies.h for jiffies timeout and wait helpers, and use them separately from i915 and display. This helps reduce the display dependency on i915_utils.h. Long term, both msecs_to_jiffies_timeout() and wait_remaining_ms_from_jiffies() really belong in core kernel headers, but for now unblock display refactoring. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Link: https://patch.msgid.link/d8bc62b3a81afa05c849dde9b0f633572eaf5611.1761146196.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-10-31drm/i915/dsi: debug log send packet sequence contentsJani Nikula
This might help debug issues better than just debug logging the function name. v2: Debug log type as hex (Ville) Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251029084603.2254982-2-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-10-31drm/i915/dsi: log send packet sequence errorsJani Nikula
We might be getting send packet sequence errors and never know. Log them as errors. Also upgrade the not supported read commands to errors. v2: Also error log -EOPNOTSUPP (Ville) Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251029084603.2254982-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-10-31drm/panel: ilitek-ili9882t: Add support for Ilitek IL79900A-based panelsLangyan Ye
The Ilitek IL79900A display controller is similar to the ILI9882T and can be supported within the existing `panel-ilitek-ili9882t.c` driver. This patch extends the ILI9882T driver to handle IL79900A-based panels, such as the Tianma TL121BVMS07-00. The IL79900A uses a similar command sequence and initialization flow, with minor differences in power supply configuration and timing. Signed-off-by: Langyan Ye <yelangyan@huaqin.corp-partner.google.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20251031100447.253164-3-yelangyan@huaqin.corp-partner.google.com
2025-10-31drm/sched: Fix comment in drm_sched_run_job_work()Philipp Stanner
drm_sched_run_job_work() contains a comment which explains that an entity being NULL means that there is no more work to do. It can, however, also mean that there is work, but the scheduler doesn't have enough credits to process the jobs right now. Provide this detail in the comment. Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Philipp Stanner <phasta@kernel.org> Link: https://patch.msgid.link/20251028134602.94125-3-phasta@kernel.org
2025-10-31drm/i915/gt: Use standard API for seqcount read in TLB invalidationAndi Shyti
seqprop_sequence() is not intended for use outside seqlock.h. Although it is accessible as a macro, it is meant to be used only internally within the header. Replace it with its proper wrapper, raw_read_seqcount(). Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Co-developed-by: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@linux.intel.com> Cc: Christoph Lameter (Ampere) <cl@gentwo.org> Reviewed-by: Sebastian Brzezinka <sebastian.brzezinka@intel.com> Link: https://lore.kernel.org/r/20251023132802.654061-1-andi.shyti@linux.intel.com
2025-10-31drm/i915: Wait for page_sizes_gtt in gtt selftest on CHV/BXT+VTDJanusz Krzysztofik
VMA pinning to GGTT is now commited asynchronously in CHV / BXT+VDT environments to avoid lock inversion among reservation_ww and cpu_hotplug locks, the latter acquired from stop_machine(). Then, vma->resource->page_sizes_gtt the test uses as shift count may still be not populated (equal 0) after i915_vma_pin() returns. Wait for VMA bind completion in those cases to avoid shift-out-of-bounds kernel warnings and the test case failing with -EBADSLT. v2: Explain why VMA pinning is commited asynchronously on CHV/BXT+VTD (Krzysztof), - use more precise wording in commit description. Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com> Reviewed-by: Sebastian Brzezinka <sebastian.brzezinka@intel.com> Reviewed-by: Krzysztof Karas <krzysztof.karas@intel.com> Acked-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://lore.kernel.org/r/20251023082925.351307-8-janusz.krzysztofik@linux.intel.com
2025-10-31drm/i915: Wait longer for threads in migrate selftest on CHV/BXT+VTDJanusz Krzysztofik
When running on a Cherryview, or on a Broxton with VTD enabled, pinning of a VMA to GGTT is now committed asynchronously to avoid lock inversion among reservation_ww and cpu_hotplug locks, the latter acquired from stop_machine(). That may defer further processing of resources that depend on that VMA. As a consequence, a 10ms delay in a multithreaded migrate test case may occur too short and still incomplete threads may be interrupted, and the test case may fail with -ERESTARTSYS or -EINTR error code returned by any of those threads. Extend the delay to empirically determined 100ms on affected platforms. v3: Add an in-line comment that explains why 100ms (Andi). v2: Fix spelling (Sebastian, Krzysztof), - explain why VMA pinning is commited asynchronously on CHV/BXT+VTD (Krzysztof). Cc: Andi Shyti <andi.shyti@kernel.org> Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com> Reviewed-by: Sebastian Brzezinka <sebastian.brzezinka@intel.com> Reviewed-by: Krzysztof Karas <krzysztof.karas@intel.com> Acked-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://lore.kernel.org/r/20251023082925.351307-7-janusz.krzysztofik@linux.intel.com
2025-10-31drm/i915: Avoid lock inversion when pinning to GGTT on CHV/BXT+VTDJanusz Krzysztofik
On completion of i915_vma_pin_ww(), a synchronous variant of dma_fence_work_commit() is called. When pinning a VMA to GGTT address space on a Cherry View family processor, or on a Broxton generation SoC with VTD enabled, i.e., when stop_machine() is then called from intel_ggtt_bind_vma(), that can potentially lead to lock inversion among reservation_ww and cpu_hotplug locks. [86.861179] ====================================================== [86.861193] WARNING: possible circular locking dependency detected [86.861209] 6.15.0-rc5-CI_DRM_16515-gca0305cadc2d+ #1 Tainted: G U [86.861226] ------------------------------------------------------ [86.861238] i915_module_loa/1432 is trying to acquire lock: [86.861252] ffffffff83489090 (cpu_hotplug_lock){++++}-{0:0}, at: stop_machine+0x1c/0x50 [86.861290] but task is already holding lock: [86.861303] ffffc90002e0b4c8 (reservation_ww_class_mutex){+.+.}-{3:3}, at: i915_vma_pin.constprop.0+0x39/0x1d0 [i915] [86.862233] which lock already depends on the new lock. [86.862251] the existing dependency chain (in reverse order) is: [86.862265] -> #5 (reservation_ww_class_mutex){+.+.}-{3:3}: [86.862292] dma_resv_lockdep+0x19a/0x390 [86.862315] do_one_initcall+0x60/0x3f0 [86.862334] kernel_init_freeable+0x3cd/0x680 [86.862353] kernel_init+0x1b/0x200 [86.862369] ret_from_fork+0x47/0x70 [86.862383] ret_from_fork_asm+0x1a/0x30 [86.862399] -> #4 (reservation_ww_class_acquire){+.+.}-{0:0}: [86.862425] dma_resv_lockdep+0x178/0x390 [86.862440] do_one_initcall+0x60/0x3f0 [86.862454] kernel_init_freeable+0x3cd/0x680 [86.862470] kernel_init+0x1b/0x200 [86.862482] ret_from_fork+0x47/0x70 [86.862495] ret_from_fork_asm+0x1a/0x30 [86.862509] -> #3 (&mm->mmap_lock){++++}-{3:3}: [86.862531] down_read_killable+0x46/0x1e0 [86.862546] lock_mm_and_find_vma+0xa2/0x280 [86.862561] do_user_addr_fault+0x266/0x8e0 [86.862578] exc_page_fault+0x8a/0x2f0 [86.862593] asm_exc_page_fault+0x27/0x30 [86.862607] filldir64+0xeb/0x180 [86.862620] kernfs_fop_readdir+0x118/0x480 [86.862635] iterate_dir+0xcf/0x2b0 [86.862648] __x64_sys_getdents64+0x84/0x140 [86.862661] x64_sys_call+0x1058/0x2660 [86.862675] do_syscall_64+0x91/0xe90 [86.862689] entry_SYSCALL_64_after_hwframe+0x76/0x7e [86.862703] -> #2 (&root->kernfs_rwsem){++++}-{3:3}: [86.862725] down_write+0x3e/0xf0 [86.862738] kernfs_add_one+0x30/0x3c0 [86.862751] kernfs_create_dir_ns+0x53/0xb0 [86.862765] internal_create_group+0x134/0x4c0 [86.862779] sysfs_create_group+0x13/0x20 [86.862792] topology_add_dev+0x1d/0x30 [86.862806] cpuhp_invoke_callback+0x4b5/0x850 [86.862822] cpuhp_issue_call+0xbf/0x1f0 [86.862836] __cpuhp_setup_state_cpuslocked+0x111/0x320 [86.862852] __cpuhp_setup_state+0xb0/0x220 [86.862866] topology_sysfs_init+0x30/0x50 [86.862879] do_one_initcall+0x60/0x3f0 [86.862893] kernel_init_freeable+0x3cd/0x680 [86.862908] kernel_init+0x1b/0x200 [86.862921] ret_from_fork+0x47/0x70 [86.862934] ret_from_fork_asm+0x1a/0x30 [86.862947] -> #1 (cpuhp_state_mutex){+.+.}-{3:3}: [86.862969] __mutex_lock+0xaa/0xed0 [86.862982] mutex_lock_nested+0x1b/0x30 [86.862995] __cpuhp_setup_state_cpuslocked+0x67/0x320 [86.863012] __cpuhp_setup_state+0xb0/0x220 [86.863026] page_alloc_init_cpuhp+0x2d/0x60 [86.863041] mm_core_init+0x22/0x2d0 [86.863054] start_kernel+0x576/0xbd0 [86.863068] x86_64_start_reservations+0x18/0x30 [86.863084] x86_64_start_kernel+0xbf/0x110 [86.863098] common_startup_64+0x13e/0x141 [86.863114] -> #0 (cpu_hotplug_lock){++++}-{0:0}: [86.863135] __lock_acquire+0x1635/0x2810 [86.863152] lock_acquire+0xc4/0x2f0 [86.863166] cpus_read_lock+0x41/0x100 [86.863180] stop_machine+0x1c/0x50 [86.863194] bxt_vtd_ggtt_insert_entries__BKL+0x3b/0x60 [i915] [86.863987] intel_ggtt_bind_vma+0x43/0x70 [i915] [86.864735] __vma_bind+0x55/0x70 [i915] [86.865510] fence_work+0x26/0xa0 [i915] [86.866248] fence_notify+0xa1/0x140 [i915] [86.866983] __i915_sw_fence_complete+0x8f/0x270 [i915] [86.867719] i915_sw_fence_commit+0x39/0x60 [i915] [86.868453] i915_vma_pin_ww+0x462/0x1360 [i915] [86.869228] i915_vma_pin.constprop.0+0x133/0x1d0 [i915] [86.870001] initial_plane_vma+0x307/0x840 [i915] [86.870774] intel_initial_plane_config+0x33f/0x670 [i915] [86.871546] intel_display_driver_probe_nogem+0x1c6/0x260 [i915] [86.872330] i915_driver_probe+0x7fa/0xe80 [i915] [86.873057] i915_pci_probe+0xe6/0x220 [i915] [86.873782] local_pci_probe+0x47/0xb0 [86.873802] pci_device_probe+0xf3/0x260 [86.873817] really_probe+0xf1/0x3c0 [86.873833] __driver_probe_device+0x8c/0x180 [86.873848] driver_probe_device+0x24/0xd0 [86.873862] __driver_attach+0x10f/0x220 [86.873876] bus_for_each_dev+0x7f/0xe0 [86.873892] driver_attach+0x1e/0x30 [86.873904] bus_add_driver+0x151/0x290 [86.873917] driver_register+0x5e/0x130 [86.873931] __pci_register_driver+0x7d/0x90 [86.873945] i915_pci_register_driver+0x23/0x30 [i915] [86.874678] i915_init+0x37/0x120 [i915] [86.875347] do_one_initcall+0x60/0x3f0 [86.875369] do_init_module+0x97/0x2a0 [86.875385] load_module+0x2c54/0x2d80 [86.875398] init_module_from_file+0x96/0xe0 [86.875413] idempotent_init_module+0x117/0x330 [86.875426] __x64_sys_finit_module+0x77/0x100 [86.875440] x64_sys_call+0x24de/0x2660 [86.875454] do_syscall_64+0x91/0xe90 [86.875470] entry_SYSCALL_64_after_hwframe+0x76/0x7e [86.875486] other info that might help us debug this: [86.875502] Chain exists of: cpu_hotplug_lock --> reservation_ww_class_acquire --> reservation_ww_class_mutex [86.875539] Possible unsafe locking scenario: [86.875552] CPU0 CPU1 [86.875563] ---- ---- [86.875573] lock(reservation_ww_class_mutex); [86.875588] lock(reservation_ww_class_acquire); [86.875606] lock(reservation_ww_class_mutex); [86.875624] rlock(cpu_hotplug_lock); [86.875637] *** DEADLOCK *** [86.875650] 3 locks held by i915_module_loa/1432: [86.875663] #0: ffff888101f5c1b0 (&dev->mutex){....}-{3:3}, at: __driver_attach+0x104/0x220 [86.875699] #1: ffffc90002e0b4a0 (reservation_ww_class_acquire){+.+.}-{0:0}, at: i915_vma_pin.constprop.0+0x39/0x1d0 [i915] [86.876512] #2: ffffc90002e0b4c8 (reservation_ww_class_mutex){+.+.}-{3:3}, at: i915_vma_pin.constprop.0+0x39/0x1d0 [i915] [86.877305] stack backtrace: [86.877326] CPU: 0 UID: 0 PID: 1432 Comm: i915_module_loa Tainted: G U 6.15.0-rc5-CI_DRM_16515-gca0305cadc2d+ #1 PREEMPT(voluntary) [86.877334] Tainted: [U]=USER [86.877336] Hardware name: /NUC5CPYB, BIOS PYBSWCEL.86A.0079.2020.0420.1316 04/20/2020 [86.877339] Call Trace: [86.877344] <TASK> [86.877353] dump_stack_lvl+0x91/0xf0 [86.877364] dump_stack+0x10/0x20 [86.877369] print_circular_bug+0x285/0x360 [86.877379] check_noncircular+0x135/0x150 [86.877390] __lock_acquire+0x1635/0x2810 [86.877403] lock_acquire+0xc4/0x2f0 [86.877408] ? stop_machine+0x1c/0x50 [86.877422] ? __pfx_bxt_vtd_ggtt_insert_entries__cb+0x10/0x10 [i915] [86.878173] cpus_read_lock+0x41/0x100 [86.878182] ? stop_machine+0x1c/0x50 [86.878191] ? __pfx_bxt_vtd_ggtt_insert_entries__cb+0x10/0x10 [i915] [86.878916] stop_machine+0x1c/0x50 [86.878927] bxt_vtd_ggtt_insert_entries__BKL+0x3b/0x60 [i915] [86.879652] intel_ggtt_bind_vma+0x43/0x70 [i915] [86.880375] __vma_bind+0x55/0x70 [i915] [86.881133] fence_work+0x26/0xa0 [i915] [86.881851] fence_notify+0xa1/0x140 [i915] [86.882566] __i915_sw_fence_complete+0x8f/0x270 [i915] [86.883286] i915_sw_fence_commit+0x39/0x60 [i915] [86.884003] i915_vma_pin_ww+0x462/0x1360 [i915] [86.884756] ? i915_vma_pin.constprop.0+0x6c/0x1d0 [i915] [86.885513] i915_vma_pin.constprop.0+0x133/0x1d0 [i915] [86.886281] initial_plane_vma+0x307/0x840 [i915] [86.887049] intel_initial_plane_config+0x33f/0x670 [i915] [86.887819] intel_display_driver_probe_nogem+0x1c6/0x260 [i915] [86.888587] i915_driver_probe+0x7fa/0xe80 [i915] [86.889293] ? mutex_unlock+0x12/0x20 [86.889301] ? drm_privacy_screen_get+0x171/0x190 [86.889308] ? acpi_dev_found+0x66/0x80 [86.889321] i915_pci_probe+0xe6/0x220 [i915] [86.890038] local_pci_probe+0x47/0xb0 [86.890049] pci_device_probe+0xf3/0x260 [86.890058] really_probe+0xf1/0x3c0 [86.890067] __driver_probe_device+0x8c/0x180 [86.890072] driver_probe_device+0x24/0xd0 [86.890078] __driver_attach+0x10f/0x220 [86.890083] ? __pfx___driver_attach+0x10/0x10 [86.890088] bus_for_each_dev+0x7f/0xe0 [86.890097] driver_attach+0x1e/0x30 [86.890101] bus_add_driver+0x151/0x290 [86.890107] driver_register+0x5e/0x130 [86.890113] __pci_register_driver+0x7d/0x90 [86.890119] i915_pci_register_driver+0x23/0x30 [i915] [86.890833] i915_init+0x37/0x120 [i915] [86.891482] ? __pfx_i915_init+0x10/0x10 [i915] [86.892135] do_one_initcall+0x60/0x3f0 [86.892145] ? __kmalloc_cache_noprof+0x33f/0x470 [86.892157] do_init_module+0x97/0x2a0 [86.892164] load_module+0x2c54/0x2d80 [86.892168] ? __kernel_read+0x15c/0x300 [86.892185] ? kernel_read_file+0x2b1/0x320 [86.892195] init_module_from_file+0x96/0xe0 [86.892199] ? init_module_from_file+0x96/0xe0 [86.892211] idempotent_init_module+0x117/0x330 [86.892224] __x64_sys_finit_module+0x77/0x100 [86.892230] x64_sys_call+0x24de/0x2660 [86.892236] do_syscall_64+0x91/0xe90 [86.892243] ? irqentry_exit+0x77/0xb0 [86.892249] ? sysvec_apic_timer_interrupt+0x57/0xc0 [86.892256] entry_SYSCALL_64_after_hwframe+0x76/0x7e [86.892261] RIP: 0033:0x7303e1b2725d [86.892271] Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 8b bb 0d 00 f7 d8 64 89 01 48 [86.892276] RSP: 002b:00007ffddd1fdb38 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 [86.892281] RAX: ffffffffffffffda RBX: 00005d771d88fd90 RCX: 00007303e1b2725d [86.892285] RDX: 0000000000000000 RSI: 00005d771d893aa0 RDI: 000000000000000c [86.892287] RBP: 00007ffddd1fdbf0 R08: 0000000000000040 R09: 00007ffddd1fdb80 [86.892289] R10: 00007303e1c03b20 R11: 0000000000000246 R12: 00005d771d893aa0 [86.892292] R13: 0000000000000000 R14: 00005d771d88f0d0 R15: 00005d771d895710 [86.892304] </TASK> Call asynchronous variant of dma_fence_work_commit() in that case. v3: Provide more verbose in-line comment (Andi), - mention target environments in commit message. Fixes: 7d1c2618eac59 ("drm/i915: Take reservation lock around i915_vma_pin.") Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/14985 Cc: Andi Shyti <andi.shyti@kernel.org> Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com> Reviewed-by: Sebastian Brzezinka <sebastian.brzezinka@intel.com> Reviewed-by: Krzysztof Karas <krzysztof.karas@intel.com> Acked-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://lore.kernel.org/r/20251023082925.351307-6-janusz.krzysztofik@linux.intel.com
2025-10-31drm/ttm: Add an allocation flag to propagate -ENOSPC on OOMTvrtko Ursulin
Some graphics APIs differentiate between out-of-graphics-memory and out-of-host-memory (system memory). Add a device init flag to have -ENOSPC propagated from the resource managers instead of being converted to -ENOMEM, to aid driver stacks in determining what error code to return or whether corrective action can be taken at the driver level. Co-developed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Christian König <christian.koenig@amd.com> Cc: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> Link: https://lore.kernel.org/r/20251020115411.36818-7-tvrtko.ursulin@igalia.com
2025-10-31drm/amdgpu: Configure max beneficial TTM pool allocation orderTvrtko Ursulin
Let the TTM pool allocator know that we can afford for it to expend less effort for satisfying contiguous allocations larger than 2MiB. The latter is the maximum relevant PTE entry size and the driver and hardware are happy to get larger blocks only opportunistically. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: Thadeu Lima de Souza Cascardo <cascardo@igalia.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> Link: https://lore.kernel.org/r/20251020115411.36818-6-tvrtko.ursulin@igalia.com
2025-10-31drm/ttm: Allow drivers to specify maximum beneficial TTM pool sizeTvrtko Ursulin
GPUs typically benefit from contiguous memory via reduced TLB pressure and improved caching performance, where the maximum size of contiguous block which adds a performance benefit is related to hardware design. TTM pool allocator by default tries (hard) to allocate up to the system MAX_PAGE_ORDER blocks. This varies by the CPU platform and can also be configured via Kconfig. If that limit was set to be higher than the GPU can make an extra use of, lets allow the individual drivers to let TTM know over which allocation order can the pool allocator afford to make a little bit less effort with. We implement this by disabling direct reclaim for those allocations, which reduces the allocation latency and lowers the demands on the page allocator, in cases where expending this effort is not critical for the GPU in question. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Christian König <christian.koenig@amd.com> Cc: Thadeu Lima de Souza Cascardo <cascardo@igalia.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> Link: https://lore.kernel.org/r/20251020115411.36818-5-tvrtko.ursulin@igalia.com
2025-10-31drm/ttm: Replace multiple booleans with flags in device initTvrtko Ursulin
Multiple consecutive boolean function arguments are usually not very readable. Replace the ones in ttm_device_init() with flags with the additional benefit of soon being able to pass in more data with just a one off code base churning cost. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: Danilo Krummrich <dakr@kernel.org> Cc: Dave Airlie <airlied@redhat.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Lyude Paul <lyude@redhat.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Sui Jingfeng <suijingfeng@loongson.cn> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Zack Rusin <zack.rusin@broadcom.com> Acked-by: Christian König <christian.koenig@amd.com> Acked-by: Zack Rusin <zack.rusin@broadcom.com> Acked-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> # For xe Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> Link: https://lore.kernel.org/r/20251020115411.36818-4-tvrtko.ursulin@igalia.com [tursulin: fixup checkpatch while applying]
2025-10-31drm/ttm: Replace multiple booleans with flags in pool initTvrtko Ursulin
Multiple consecutive boolean function arguments are usually not very readable. Replace the ones in ttm_pool_init() with flags with the additional benefit of soon being able to pass in more data with just this one code base churning cost. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> Link: https://lore.kernel.org/r/20251020115411.36818-3-tvrtko.ursulin@igalia.com
2025-10-31drm/ttm: Add getter for some pool propertiesTvrtko Ursulin
No functional change but to allow easier refactoring in the future. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Christian König <christian.koenig@amd.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> Link: https://lore.kernel.org/r/20251020115411.36818-2-tvrtko.ursulin@igalia.com
2025-10-31drm: include drm_print.h where neededJani Nikula
There are a gazillion files that depend on drm_print.h being indirectly included via drm_buddy.h, drm_mm.h, or ttm/ttm_resource.h. In preparation for removing those includes, explicitly include drm_print.h where needed. Cc: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://lore.kernel.org/r/5fe67395907be33eb5199ea6d540e29fddee71c8.1761734313.git.jani.nikula@intel.com
2025-10-30drm/xe/gt_throttle: Drop individual show functionsLucas De Marchi
They are all doing the same thing with the mask being the param. Just declare our own attribute to store the mask and provide a single function. Another common pattern is to define the show function in the macro, however on follow up work the mask may be used for returning more information, so it'd need to be stored in any case. Reviewed-by: Raag Jadav <raag.jadav@intel.com> Link: https://patch.msgid.link/20251029-gt-throttle-cri-v3-7-d1f5abbb8114@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-10-30drm/xe: Improve freq and throttle documentationLucas De Marchi
Add xe_gt_throttle under the "GT Frequency Management" and improve the narrative making sure the documentation for both *_freq and throttle/* attributes follow the same style. Reviewed-by: Raag Jadav <raag.jadav@intel.com> Link: https://patch.msgid.link/20251029-gt-throttle-cri-v3-6-d1f5abbb8114@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-10-30drm/xe/gt_throttle: Tidy up attribute definitionLucas De Marchi
Move the attribute definitions to be grouped together rather than near the show() function: checkpatch keeps complaining about the missing newline when defining new attributes and it reads better to group everything, which should match e.g. the xe_pmu.c style. While grouping them, also define a THROTTLE_ATTR_RO(), similar to DEVICE_ATTR_RO(), and use it to define all attributes. This makes it shorter and with a familiar syntax. Finally, during the cri_throttle_attrs[] array definition, also highlight what's coming from common attributes and what is CRI-specific. These 3 things could be done as separate commits, but they are all about the same thing: reduce the attribute definition verbosity and are very simple and mechanical. Reviewed-by: Raag Jadav <raag.jadav@intel.com> Link: https://patch.msgid.link/20251029-gt-throttle-cri-v3-5-d1f5abbb8114@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-10-30drm/xe/gt_throttle: Add throttle_to_gt()Lucas De Marchi
Reduce boilerplate code by adding a helper to go directly from the throttle kobject to the gt. Note that there's already a kobj_to_gt(), but that actually converts our kobj_gt object to gt. Reviewed-by: Raag Jadav <raag.jadav@intel.com> Link: https://patch.msgid.link/20251029-gt-throttle-cri-v3-4-d1f5abbb8114@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-10-30drm/xe/gt_throttle: Always read and maskLucas De Marchi
Use a single function to read and mask the value the callers will be interested in. This reduces the risk of a caller using a plain call to xe_gt_throttle_get_limit_reasons() without applying any mask, which can return unexpected bits for future platforms. Select which reg and mask it's going to be used according to the platform and gt type and always use that one function. There was an odd xe_gt_dbg() when reading the status, which is not done for any other throttle/* sysfs file, so just make the status be as special as everybody else. Reviewed-by: Raag Jadav <raag.jadav@intel.com> Link: https://patch.msgid.link/20251029-gt-throttle-cri-v3-3-d1f5abbb8114@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-10-30drm/xe/gt_throttle: Tidy up perf reasons readingLucas De Marchi
There's no need to be so verbose with two functions per bit: read_reason_xxxxx() and reason_xxxxx_show(). Drop the former and just use a new is_throttled_by() that receives the mask as parameter. Reviewed-by: Raag Jadav <raag.jadav@intel.com> Link: https://patch.msgid.link/20251029-gt-throttle-cri-v3-2-d1f5abbb8114@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-10-30drm/xe/cri: Add new performance limit reasons bitsSk Anirban
Crescent Island has some additional and different bits for performance limit reasons. Add the new definitions and use them for CRI. Signed-off-by: Sk Anirban <sk.anirban@intel.com> Reviewed-by: Raag Jadav <raag.jadav@intel.com> Link: https://patch.msgid.link/20251029-gt-throttle-cri-v3-1-d1f5abbb8114@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-10-30drm/client: Flush client buffers with drm_client_buffer_sync()Thomas Zimmermann
Rename drm_client_framebuffer_flush() to drm_cient_buffer_flush() and adapt its callers. The old name was left over from previous naming conventions. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>> Tested-by: Francesco Valla <francesco@valla.it> Link: https://patch.msgid.link/20251027121042.143588-8-tzimmermann@suse.de
2025-10-30drm/client: Create client buffers with drm_client_buffer_create_dumb()Thomas Zimmermann
Rename drm_client_framebuffer_create() to drm_client_buffer_create_dump() and adapt callers. The new name reflects the function's purpose. Using dumb buffers is the easiest way for creating a GEM buffer in a drivers- independent way. There's also drm_client_buffer_create(), which creates the client buffer from a preexisting buffer object. This helper can be exported for drivers that create their own GEM buffer object. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Tested-by: Francesco Valla <francesco@valla.it> Link: https://patch.msgid.link/20251027121042.143588-7-tzimmermann@suse.de
2025-10-30drm/client: Remove drm_client_framebuffer_delete()Thomas Zimmermann
Release client buffers with drm_client_buffer_delete() instead of drm_client_framebuffer_delete(). The latter is just a tiny wrapper around the former. Move the test for !buffer into drm_client_buffer_delete(), although all callers appear to always have a valid pointer. v2: - test for !buffer before deref-ing pointer (Jocelyn, Dan) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Tested-by: Francesco Valla <francesco@valla.it> Link: https://patch.msgid.link/20251027121042.143588-6-tzimmermann@suse.de
2025-10-30drm/client: Deprecate struct drm_client_buffer.gemThomas Zimmermann
The client buffer's framebuffer holds a reference and pointer on each of its GEM buffer objects. Thus the field gem in the client- buffer struct is not necessary. Deprecated the field and convert the client-buffer helpers to use the framebuffer's objects. In drm_client_buffer_delete(), do a possible vunmap before releasing the framebuffer. Otherwise we'd eventually release the framebuffer before unmaping its buffer objects. v2: - avoid dependency on CONFIG_DRM_KMS_HELPER Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Tested-by: Francesco Valla <francesco@valla.it> Link: https://patch.msgid.link/20251027121042.143588-5-tzimmermann@suse.de
2025-10-30drm/client: Inline drm_client_buffer_addfb() and _rmfb()Thomas Zimmermann
Creating and deleting a client buffer always creates and deletes the underlying DRM framebuffer. Inline the helper functions into their callers. With the _addfb code being inlined into drm_client_buffer_create(), clean up the function's error rollback to release the framebuffer's handle and GEM buffer object as needed. Move the _rmfb code into drm_client_buffer_delete() rather than its current location in drm_client_framebuffer_delete(). The former is now the inverse of drm_client_buffer_create(). Makes no difference for cleaning up. Also prepares for the removal of drm_client_framebuffer_delete(). Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Tested-by: Francesco Valla <francesco@valla.it> Link: https://patch.msgid.link/20251027121042.143588-4-tzimmermann@suse.de
2025-10-30drm/client: Move dumb-buffer handling to drm_client_framebuffer_create()Thomas Zimmermann
Dumb-buffer creation within the client code is asymetrically balanced across drm_client_buffer_create() and drm_client_framebuffer_create(). Put all dumb-buffer code into drm_client_framebuffer_create() and leave client-buffer initialization to drm_client_buffer_create(). Clarifies responsibility between these functions. Apart form the architectural improvements, drm_client_buffer_create() can now be exported if needed by clients. The client will be able to initialize buffers that have been created from other interfaces than dumb buffers. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Tested-by: Francesco Valla <francesco@valla.it> Link: https://patch.msgid.link/20251027121042.143588-3-tzimmermann@suse.de
generated by cgit v1.2.3 (git 2.46.0) at 2026-05-19 13:00:42 +0000