summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm
AgeCommit message (Collapse)Author
2025-12-22drm/xe/vf: Check if scheduler groups are enabledDaniele Ceraolo Spurio
VF can check if PF has enabled scheduler groups with a dedicated KLV query. If scheduler groups are enabled, MLRC queue registrations are forbidden. Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patch.msgid.link/20251218223846.1146344-20-daniele.ceraolospurio@intel.com
2025-12-22drm/xe/pf: Scheduler groups are incompatible with multi-lrcDaniele Ceraolo Spurio
Since engines in the same class can be divided across multiple groups, the GuC does not allow scheduler groups to be active if there are multi-lrc contexts. This means that: 1) if a MLRC context is registered when we enable scheduler groups, the GuC will silently ignore the configuration 2) if a MLRC context is registered after scheduler groups are enabled, the GuC will disable the groups and generate an adverse event. The expectation is that the admin will ensure that all apps that use MLRC on PF have been terminated before scheduler groups are created. A check is added anyway to make sure we don't still have contexts waiting to be cleaned up laying around. A check is also added at queue creation time to block MLRC queue creation if scheduler groups have been enabled. Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patch.msgid.link/20251218223846.1146344-19-daniele.ceraolospurio@intel.com
2025-12-22drm/xe/pf: Add support for enabling scheduler groupsDaniele Ceraolo Spurio
Scheduler groups are enabled by sending a specific policy configuration KLV to the GuC. We don't allow changing this policy if there are VF active, since the expectation is that the VF will only check if the feature is enabled during driver initialization. While the GuC interface supports a maximum of 8 groups, the actual number of groups that can be enabled can be lower than that and can be different on different devices. For now, all devices support up to 2 groups, so we check that we do not have more groups than that. The functions added by this patch will be used by sysfs/debugfs, coming in follow up patches. Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patch.msgid.link/20251218223846.1146344-18-daniele.ceraolospurio@intel.com
2025-12-22drm/xe/pf: Initialize scheduler groupsDaniele Ceraolo Spurio
Scheduler groups (a.k.a. Engine Groups Scheduling, or EGS) is a GuC feature that allows the driver to define groups of engines that are independently scheduled across VFs, which allows different VFs to be active on the HW at the same time on different groups. The feature is available for BMG and newer HW starting on GuC 70.53.0, but some required fixes have been added to GuC 70.55.1. This is intended for specific scenarios where the admin knows that the VFs are not going to fully utilize the HW and therefore assigning all of it to a single VF would lead to part of it being permanently idle. We do not allow the admin to decide how to divide the engines across groups, but we instead support specific configurations that are designed for specific use-cases. During PF initialization we detect which configurations are possible on a given GT and create the relevant groups. Since the GuC expect a mask for each class for each group, that is what we save when we init the configs. Right now we only have one use-case on the media GT. If the VFs are running a frame render + encoding at a not-too-high resolution (e.g. 1080@30fps) the render can produce frames faster than the video engine can encode them, which means that the maximum number of parallel VFs is limited by the VCS bandwidth. Since our products can have multiple VCS engines, allowing multiple VFs to be active on the different VCS engines at the same time allows us to run more parallel VFs on the same HW. Given that engines in the same media slice share some resources (e.g. SFC), we assign each media slice to a different scheduling group. We refer to this configuration as "media_slices", given that each slice gets its own group. Since upcoming products have a different number of video engines per-slice, for now we limit the media_slices mode to BMG, but we expect to add support for newer HW soon. Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patch.msgid.link/20251218223846.1146344-17-daniele.ceraolospurio@intel.com
2025-12-22drm/gt/guc: extract scheduler-related defines from guc_fwif.hDaniele Ceraolo Spurio
Some upcoming KLVs are sized based on the engine counts, so we need those defines to be moved to a separate file to include them from guc_klv_abi.h (which is already included by guc_fwif.h). Instead of moving just the engine-related defines, it is cleaner to move all scheduler-related defines (i.e., everything engine or context related). Note that the legacy GuC defines have not been moved and have instead been dropped because Xe doesn't support any GuC old enough to still use them. While at it, struct guc_ctxt_registration_info has been moved to guc_submit.c since it doesn't come from the GuC specs (we added it to make things simpler in our code). Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patch.msgid.link/20251218223846.1146344-16-daniele.ceraolospurio@intel.com
2025-12-22drm/xe/gt: Add engine masks for each classDaniele Ceraolo Spurio
Follow up patches will need the engine masks for VCS and VECS engines. Since we already have a macro for the CCS engines, just extend the same approach to all classes. To avoid confusion with the XE_HW_ENGINE_*_MASK masks, the new macros use the _INSTANCES suffix instead. For consistency, rename CCS_MASK to CCS_INSTANCES as well. Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patch.msgid.link/20251218223846.1146344-15-daniele.ceraolospurio@intel.com
2025-12-22drm: tyr: replace `kernel::c_str!` with C-StringsTamir Duberstein
C-String literals were added in Rust 1.77. Replace instances of `kernel::c_str!` with C-String literals where possible. Signed-off-by: Tamir Duberstein <tamird@gmail.com> Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Link: https://patch.msgid.link/20251222-cstr-tyr-v1-1-d88ff1a54ae9@gmail.com [ Change commit subject prefix to 'drm: tyr:'. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-12-22gpu: nova: replace `kernel::c_str!` with C-StringsTamir Duberstein
C-String literals were added in Rust 1.77. Replace instances of `kernel::c_str!` with C-String literals where possible. Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Benno Lossin <lossin@kernel.org> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Tamir Duberstein <tamird@gmail.com> Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Link: https://patch.msgid.link/20251222-cstr-nova-v1-1-0e2353d5debe@gmail.com [ Use 'nova' commit subject prefix; use kernel vertical import style. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-12-22drm/atomic: convert drm_atomic_get_{old, new}_colorop_state() into proper ↵Jani Nikula
functions There is no real reason to include drm_colorop.h from drm_atomic.h, as drm_atomic_get_{old,new}_colorop_state() have no real reason to be static inline. Convert the static inlines to proper functions, and drop the include to reduce the include dependencies and improve data hiding. v2: Fix vkms build failures (Alex) Fixes: cfc27680ee20 ("drm/colorop: Introduce new drm_colorop mode object") Cc: Simon Ser <contact@emersion.fr> Cc: Alex Hung <alex.hung@amd.com> Cc: Harry Wentland <harry.wentland@amd.com> Cc: Daniel Stone <daniels@collabora.com> Cc: Melissa Wen <mwen@igalia.com> Cc: Sebastian Wick <sebastian.wick@redhat.com> Cc: Alex Hung <alex.hung@amd.com> Reviewed-by: Alex Hung <alex.hung@amd.com> Link: https://patch.msgid.link/20251219114939.1069851-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-12-22drm/xe/display: drop i915_utils.hJani Nikula
With the i915 switch to generic fault injection, display no longer needs the compat i915_utils.h. Remove it, along with a few includes. Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Link: https://patch.msgid.link/20251219104036.855258-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-12-22drm/i915: drop dependency on struct intel_display from i915 initial planeJani Nikula
The i915 core initial plane handling doesn't actually need struct intel_display for anything. Switch to i915 specific data structures in i915 core code. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/58d7605a16b360080921ff2af7120b6da2eb042d.1765812266.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-12-22drm/{i915, xe}: pass struct drm_device instead of drm_device to ->alloc_objJani Nikula
The initial plane parent interface ->alloc_obj hook no longer needs the crtc for anything. Pass struct drm_device instead. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/7a40381be6d98dc0916a5447be5dd6cba86cfd0a.1765812266.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-12-22drm/{i915, xe}: pass struct drm_plane_state instead of struct drm_crtc to ↵Jani Nikula
->setup The initial plane parent interface ->setup hook no longer needs the crtc for anything. Pass the struct drm_plane_state instead. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/c3db101ef5fd13c56cb3a9329adecf521a807abc.1765812266.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-12-22drm/{i915,xe}: deduplicate initial plane setupJani Nikula
Deduplicate more of the identical parts of i915 and xe initial plane setup. This lets us reduce the core dependency on display internals. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/1a2abbceedb9e7d03f262c44cd54a24556ef6b61.1765812266.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-12-22drm/{i915, xe}: deduplicate intel_alloc_initial_plane_obj() FB modifier checksJani Nikula
Move the modifier checks into common code to deduplicate. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/3c62ad48595aa2306219b1d6a215cf7680a67da2.1765812266.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-12-22drm/i915: further deduplicate intel_find_initial_plane_obj()Jani Nikula
Move intel_reuse_initial_plane_obj() into common display code, and split the ->find_obj hook into ->alloc_obj and ->setup hooks. Return the struct drm_gem_object from ->alloc_obj in preparation for moving more things to display. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/c71011dbb11afaa5c4da30aa2627833374300d63.1765812266.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-12-22drm/xe: return plane_state from intel_reuse_initial_plane_obj()Jani Nikula
Initialize fb in the same level as the other code path. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/47d3272cff13dc8f5d7323c32bfb3cc34c0c977d.1765812266.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-12-22drm/i915: return plane_state from intel_reuse_initial_plane_obj()Jani Nikula
Initialize fb and vma in the same level as the other code path. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/96985a18593408f07fba131cf49ca0f97bf8fb93.1765812266.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-12-22drm/{i915, xe}: start deduplicating intel_find_initial_plane_obj() between ↵Jani Nikula
i915 and xe Move some easy common parts to display. Initially, the intel_find_initial_plane_obj() error path seems silly, but it'll be more helpful this way for later changes. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/950d308172443d5bae975aa1ab72111720134219.1765812266.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-12-22drm/{i915, xe}: deduplicate plane_config_fini() between i915 and xeJani Nikula
Move the common code to display. Retain empty xe_plane_config_fini() for now, in case it's needed in the future. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/14322386cdb1a0f4f6c7ff74a5a9696ea0ff84bf.1765812266.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-12-22drm/{i915, xe}: deduplicate intel_initial_plane_config() between i915 and xeJani Nikula
Move the parent interface at one step lower level, allowing deduplication. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/0cb4077a5a39274c7a2dae95d548d7b33365a518.1765812266.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-12-22drm/{i915, xe}: move initial plane calls to parent interfaceJani Nikula
Add the initial plane handling functions to the display parent interface. Add the call wrappers in dedicated intel_initial_plane.c instead of intel_parent.c, as we'll be refactoring the calls heavily. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/ab91c891677fe2bb83bf5aafa5ee984b2442b84d.1765812266.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-12-22drm/i915: rename intel_plane_initial.h to intel_initial_plane.hJani Nikula
Follow the more naturally flowing naming. Rename both the header and the vblank wait function. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/32c2d68a9ae7d2262ad2c63e873e522e67bc78df.1765812266.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-12-22drm/xe/display: rename xe_plane_initial.c to xe_initial_plane.cJani Nikula
Follow i915 with the more naturally flowing naming. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/62eb56fe348a8fe7c17333d784192da701367cc7.1765812266.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-12-22drm/i915: move display/intel_plane_initial.c to i915_initial_plane.cJani Nikula
intel_plane_initial.c is i915 specific. Move it to i915 core. Start renaming stuff with the slightly more natural "initial plane" rather than "plane initial". Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/cdad733192690a61fbb44921c57fc68cc1cd809f.1765812266.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-12-22drm/xe: Fix ggtt fb alignmentTvrtko Ursulin
Pass the correct alignment from intel_fb_pin_to_ggtt() down to __xe_pin_fb_vma(). Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Closes: https://lore.kernel.org/intel-xe/aNL_RgLy13fXJbYx@intel.com/ Cc: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Fixes: b0228a337de8 ("drm/xe/display: align framebuffers according to hw requirements") Cc: <stable@vger.kernel.org> # v6.13+ Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Link: https://patch.msgid.link/20251208181550.6618-1-tursulin@igalia.com
2025-12-21drm/ast: Swap framebuffer writes on big-endian machinesRené Rebe
Swap the pixel data when writing to framebuffer memory on big-endian machines. Fixes incorrect output. Aspeed graphics does not appear to support big-endian framebuffers after AST2400, although the feature has been documented. There's a lengthy discussion at [1]. v5: - avoid restricted cast from __be16 (kernel test robot) Signed-off-by: René Rebe <rene@exactco.de> Link: https://lore.kernel.org/dri-devel/20251202.170626.2134482663677806825.rene@exactco.de/ # [1] Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20251212.210504.1355099120650239629.rene@exactco.de
2025-12-21drm/gem-shmem: Fix the MODULE_LICENSE() stringThomas Zimmermann
Replace the bogus "GPL v2" with "GPL" as MODULE_LICNSE() string. The value does not declare the module's exact license, but only lets the module loader test whether the module is Free Software or not. See commit bf7fbeeae6db ("module: Cure the MODULE_LICENSE "GPL" vs. "GPL v2" bogosity") in the details of the issue. The fix is to use "GPL" for all modules under any variant of the GPL. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Fixes: 4b2b5e142ff4 ("drm: Move GEM memory managers into modules") Link: https://patch.msgid.link/20251209140141.94407-3-tzimmermann@suse.de
2025-12-21drm/gem-shmem: Fix typos in documentationThomas Zimmermann
Fix the compile-time warnings Warning: drm_gem_shmem_helper.c:104 function parameter 'shmem' not described in 'drm_gem_shmem_init' Warning: drm_gem_shmem_helper.c:104 function parameter 'size' not described in 'drm_gem_shmem_init' Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Fixes: e3f4bdaf2c5b ("drm/gem/shmem: Extract drm_gem_shmem_init() from drm_gem_shmem_create()") Link: https://patch.msgid.link/20251209140141.94407-2-tzimmermann@suse.de
2025-12-21drm/tests: shmem: Hold reservation lock around purgeThomas Zimmermann
Acquire and release the GEM object's reservation lock around calls to the object's purge operation. The tests use drm_gem_shmem_purge_locked(), which led to errors such as show below. [ 58.709128] WARNING: CPU: 1 PID: 1354 at drivers/gpu/drm/drm_gem_shmem_helper.c:515 drm_gem_shmem_purge_locked+0x51c/0x740 Only export the new helper drm_gem_shmem_purge() for Kunit tests. This is not an interface for regular drivers. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Fixes: 954907f7147d ("drm/shmem-helper: Refactor locked/unlocked functions") Cc: dri-devel@lists.freedesktop.org Cc: <stable@vger.kernel.org> # v6.16+ Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://patch.msgid.link/20251212160317.287409-6-tzimmermann@suse.de
2025-12-21drm/tests: shmem: Hold reservation lock around madviseThomas Zimmermann
Acquire and release the GEM object's reservation lock around calls to the object's madvide operation. The tests use drm_gem_shmem_madvise_locked(), which led to errors such as show below. [ 58.339389] WARNING: CPU: 1 PID: 1352 at drivers/gpu/drm/drm_gem_shmem_helper.c:499 drm_gem_shmem_madvise_locked+0xde/0x140 Only export the new helper drm_gem_shmem_madvise() for Kunit tests. This is not an interface for regular drivers. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Fixes: 954907f7147d ("drm/shmem-helper: Refactor locked/unlocked functions") Cc: dri-devel@lists.freedesktop.org Cc: <stable@vger.kernel.org> # v6.16+ Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://patch.msgid.link/20251212160317.287409-5-tzimmermann@suse.de
2025-12-21drm/tests: shmem: Hold reservation lock around vmap/vunmapThomas Zimmermann
Acquire and release the GEM object's reservation lock around vmap and vunmap operations. The tests use vmap_locked, which led to errors such as show below. [ 122.292030] WARNING: CPU: 3 PID: 1413 at drivers/gpu/drm/drm_gem_shmem_helper.c:390 drm_gem_shmem_vmap_locked+0x3a3/0x6f0 [ 122.468066] WARNING: CPU: 3 PID: 1413 at drivers/gpu/drm/drm_gem_shmem_helper.c:293 drm_gem_shmem_pin_locked+0x1fe/0x350 [ 122.563504] WARNING: CPU: 3 PID: 1413 at drivers/gpu/drm/drm_gem_shmem_helper.c:234 drm_gem_shmem_get_pages_locked+0x23c/0x370 [ 122.662248] WARNING: CPU: 2 PID: 1413 at drivers/gpu/drm/drm_gem_shmem_helper.c:452 drm_gem_shmem_vunmap_locked+0x101/0x330 Only export the new vmap/vunmap helpers for Kunit tests. These are not interfaces for regular drivers. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Fixes: 954907f7147d ("drm/shmem-helper: Refactor locked/unlocked functions") Cc: dri-devel@lists.freedesktop.org Cc: <stable@vger.kernel.org> # v6.16+ Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://patch.msgid.link/20251212160317.287409-4-tzimmermann@suse.de
2025-12-21drm/tests: shmem: Add clean-up action to unpin pagesThomas Zimmermann
Automatically unpin pages on cleanup. The test currently fails with the error [ 58.246263] drm-kunit-mock-device drm_gem_shmem_test_get_sg_table.drm-kunit-mock-device: [drm] drm_WARN_ON(refcount_read(&shmem->pages_pin_count)) while cleaning up the GEM object. The pin count has to be zero at this point. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Fixes: d586b535f144 ("drm/shmem-helper: Add and use pages_pin_count") Cc: dri-devel@lists.freedesktop.org Cc: <stable@vger.kernel.org> # v6.16+ Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://patch.msgid.link/20251212160317.287409-3-tzimmermann@suse.de
2025-12-21drm/tests: shmem: Swap names of export testsThomas Zimmermann
GEM SHMEM has 2 helpers for exporting S/G tables. Swap the names of the rsp. tests, so that each matches the helper it tests. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Fixes: 93032ae634d4 ("drm/test: add a test suite for GEM objects backed by shmem") Cc: dri-devel@lists.freedesktop.org Cc: <stable@vger.kernel.org> # v6.8+ Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://patch.msgid.link/20251212160317.287409-2-tzimmermann@suse.de
2025-12-21drm/panfrost: Add GPU_PM_RT support for RZ/G3E SoCBiju Das
RZ/G3E SoC is embedded with Mali-G52 GPU system. The system hangs after STR in the following condition: STR -> Wakeup from STR -> Unload panfrost using 'modprobe -r panfrost'. Fix this issue by asserting/deasserting the reset during suspend/resume. Rename the variable allwinner_h616_data->default_pm_rt_data for data reuse and make it as generic GPU PM runtime data. Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Reviewed-by: Adrián Larumbe <adrian.larumbe@collabora.com> Reviewed-by: Steven Price <steven.price@arm.com> Link: https://patch.msgid.link/20251203125104.67596-1-biju.das.jz@bp.renesas.com Signed-off-by: Adrian Larumbe <adrianml@alumnos.upm.es>
2025-12-20drm/nouveau/dispnv50: Don't call drm_atomic_get_crtc_state() in prepare_fbLyude Paul
Since we recently started warning about uses of this function after the atomic check phase completes, we've started getting warnings about this in nouveau. It appears a misplaced drm_atomic_get_crtc_state() call has been hiding in our .prepare_fb callback for a while. So, fix this by adding a new nv50_head_atom_get_new() function and use that in our .prepare_fb callback instead. Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Fixes: 1590700d94ac ("drm/nouveau/kms/nv50-: split each resource type into their own source files") Cc: <stable@vger.kernel.org> # v4.18+ Link: https://patch.msgid.link/20251211190256.396742-1-lyude@redhat.com
2025-12-19drm/msm: Fix a7xx per pipe register programmingAnna Maniscalco
GEN7_GRAS_NC_MODE_CNTL was only programmed for BR and not for BV pipe but it needs to be programmed for both. Program both pipes in hw_init and introducea separate reglist for it in order to add this register to the dynamic reglist which supports restoring registers per pipe. Fixes: 91389b4e3263 ("drm/msm/a6xx: Add a pwrup_list field to a6xx_info") Cc: stable@vger.kernel.org Reviewed-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Signed-off-by: Anna Maniscalco <anna.maniscalco2000@gmail.com> Patchwork: https://patchwork.freedesktop.org/patch/691553/ Message-ID: <20251201-gras_nc_mode_fix-v3-1-92a8a10d91d0@gmail.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2025-12-19drm/msm: add PERFCTR_CNTL to ifpc_reglistAnna Maniscalco
Previously this register would become 0 after IFPC took place which broke all usages of counters. Fixes: a6a0157cc68e ("drm/msm/a6xx: Enable IFPC on Adreno X1-85") Cc: stable@vger.kernel.org Signed-off-by: Anna Maniscalco <anna.maniscalco2000@gmail.com> Reviewed-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/690960/ Message-ID: <20251127-ifpc_counters-v3-1-fac0a126bc88@gmail.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2025-12-19drm/msm/a6xx: move preempt_prepare_postamble after error checkAlok Tiwari
Move the call to preempt_prepare_postamble() after verifying that preempt_postamble_ptr is valid. If preempt_postamble_ptr is NULL, dereferencing it in preempt_prepare_postamble() would lead to a crash. This change avoids calling the preparation function when the postamble allocation has failed, preventing potential NULL pointer dereference and ensuring proper error handling. Fixes: 50117cad0c50 ("drm/msm/a6xx: Use posamble to reset counters on preemption") Signed-off-by: Alok Tiwari <alok.a.tiwari@oracle.com> Patchwork: https://patchwork.freedesktop.org/patch/687659/ Message-ID: <20251113082839.3821867-1-alok.a.tiwari@oracle.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2025-12-19drm/msm: adreno: fix deferencing ifpc_reglist when not declaredNeil Armstrong
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 Valla
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 Valla
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 Valla
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 Brost
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 Brost
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ä
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 Sousa
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 Sousa
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 Tauro
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 Tauro
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>