aboutsummaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2025-12-22drm/xe/pf: Add functions to set exec quantums for each groupDaniele Ceraolo Spurio4-5/+181
The GuC has a new dedicated KLV to set the EQs for the groups. The GuC always sets the EQs for all the groups (even the ones not enabled). If we provide fewer values than the max number of groups (8), the GuC will set the remaining ones to 0 (infinity). Note that the new KLV can be used even when groups are disabled (as the GuC always consider group0 to be active), so we can use it when encoding the SRIOV config. 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-24-daniele.ceraolospurio@intel.com
2025-12-22drm/xe/pf: Prep for multiple exec quantums and preemption timeoutsDaniele Ceraolo Spurio3-10/+28
Each scheduler group can be independently configured with its own exec quantum and preemption timeouts. The existing KLVs to configure those parameters will apply the value to all groups (even if they're not enabled at the moment). When scheduler groups are disabled, the GuC uses the values from Group 0. 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-23-daniele.ceraolospurio@intel.com
2025-12-22drm/xe/pf: Add debugfs with scheduler groups informationDaniele Ceraolo Spurio1-0/+59
Under a new subfolder, an entry is created for each group to list the engines assigned to them. We create enough entries for each possible group, with the disabled groups just returning an empty list. 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-22-daniele.ceraolospurio@intel.com
2025-12-22drm/xe/pf: Add debugfs to enable scheduler groupsDaniele Ceraolo Spurio1-0/+126
Reading the debugfs file lists the available configurations by name. Writing the name of a configuration to the file will enable it. Note that while this debugfs is PF-only, follow up patches will add some debugfs files that are applicable to VF as well, so the function accepts a vfid parameter to be ready for that. 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-21-daniele.ceraolospurio@intel.com
2025-12-22drm/xe/vf: Check if scheduler groups are enabledDaniele Ceraolo Spurio6-0/+83
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 Spurio7-0/+93
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 Spurio5-0/+190
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 Spurio6-0/+198
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 Spurio4-54/+67
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 Spurio5-8/+15
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 Duberstein1-10/+9
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 Duberstein2-8/+15
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 Nikula6-0/+39
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 Nikula3-11/+0
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 Nikula1-26/+17
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 Nikula3-12/+7
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 Nikula3-14/+6
->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 Nikula3-50/+26
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 Nikula3-26/+14
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 Nikula3-110/+82
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 Nikula1-11/+15
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 Nikula1-12/+14
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 Nikula3-53/+37
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 Nikula3-19/+10
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 Nikula3-83/+59
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 Nikula9-8/+69
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 Nikula5-14/+14
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 Nikula2-1/+1
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 Nikula2-9/+10
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 Ursulin1-1/+1
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é Rebe2-5/+17
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 Zimmermann1-1/+1
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 Zimmermann1-1/+2
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 Zimmermann2-1/+18
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 Zimmermann2-4/+19
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 Zimmermann2-2/+37
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 Zimmermann1-0/+6
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 Zimmermann1-3/+3
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 Das1-2/+3
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 Paul2-1/+14
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 Maniscalco4-5/+55
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 Maniscalco1-0/+1
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 Tiwari1-2/+2
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 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
generated by cgit