summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2025-11-10drm/atomic: use drm_crtc_vblank_waitqueue()Jani Nikula
We have drm_crtc_vblank_waitqueue() to get the wait_queue_head_t pointer for a vblank. Use it instead of poking at dev->vblank[] directly. Due to the macro maze of wait_event_timeout() that uses the address-of operator on the argument, we have to pass it in with the indirection operator. Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/1097348197acea9110da8baebbbc189890d01660.1762513240.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-11-10drm/gma500: use drm_crtc_vblank_crtc()Jani Nikula
We have drm_crtc_vblank_crtc() to get the struct drm_vblank_crtc pointer for a crtc. Use it instead of poking at dev->vblank[] directly. However, we also need to get the crtc to start with. We could use drm_crtc_from_index(), but refactor to use drm_for_each_crtc() instead. This is all a bit tedious, and perhaps the driver shouldn't be poking at vblank->enabled directly in the first place. But at least hide away the dev->vblank[] access in drm_vblank.c where it belongs. Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Acked-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Link: https://patch.msgid.link/27b2c6772c68120d0d5ec28477db0d993743e955.1762513240.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-11-10drm/vmwgfx: use drm_crtc_vblank_crtc()Jani Nikula
We have drm_crtc_vblank_crtc() to get the struct drm_vblank_crtc pointer for a crtc. Use it instead of poking at dev->vblank[] directly. Cc: Zack Rusin <zack.rusin@broadcom.com> Cc: Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com> Reviewed-by: Ian Forbes <ian.forbes@broadcom.com> Link: https://patch.msgid.link/5157c2e927676aad75348855cf7b6745cba90003.1762513240.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-11-10drm/tidss: use drm_crtc_vblank_crtc()Jani Nikula
We have drm_crtc_vblank_crtc() to get the struct drm_vblank_crtc pointer for a crtc. Use it instead of poking at dev->vblank[] directly. Cc: Jyri Sarha <jyri.sarha@iki.fi> Cc: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Acked-by: Jyri Sarha <jyri.sarha@iki.fi> Link: https://patch.msgid.link/ffd5ebe03391b3c01e616c0c844a4b8ddecede36.1762513240.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-11-10drm/vblank: use drm_crtc_vblank_crtc() in workersJani Nikula
We have drm_crtc_vblank_crtc() to get the struct drm_vblank_crtc pointer for a crtc. Use it instead of poking at dev->vblank[] directly. Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/f046701a10340c1dcaecb1b52e41dcf2236fded1.1762513240.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-11-10drm/i915/ltphy: Return lowest portclock for HDMI from reverse algorithmSuraj Kandpal
Return the lowest port clock for HDMI when the reverse algorithm calculates it to be 0 to avoid errors later but throw a warn. Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patch.msgid.link/20251110061940.545183-2-suraj.kandpal@intel.com
2025-11-10drm/i915/ltphy: Implement HDMI Algo for Pll stateSuraj Kandpal
Implement the HDMI Algorithm to dynamically create LT PHY state based on the port clock provided. Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patch.msgid.link/20251110061940.545183-1-suraj.kandpal@intel.com
2025-11-10drm/xe/vf: Enable VF resource fixup unconditionallyMichał Winiarski
All the feature enabling code is in place - drop the debug flag requirement for VF resource fixup. Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patch.msgid.link/20251107161000.1938186-1-michal.winiarski@intel.com Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
2025-11-09Merge tag 'kbuild-fixes-6.18-3' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/kbuild/linux Pull Kbuild fixes from Nathan Chancellor: - Strip trailing padding bytes from modules.builtin.modinfo to fix error during modules_install with certain versions of kmod - Drop unused static inline function warning in .c files with clang from W=1 to W=2 - Ensure kernel-doc.py invocations use the PYTHON3 make variable to ensure user's choice of Python interpreter is always respected * tag 'kbuild-fixes-6.18-3' of git://git.kernel.org/pub/scm/linux/kernel/git/kbuild/linux: kbuild: Let kernel-doc.py use PYTHON3 override compiler_types: Move unused static inline functions warning to W=2 kbuild: Strip trailing padding bytes from modules.builtin.modinfo
2025-11-08kbuild: Let kernel-doc.py use PYTHON3 overrideJean Delvare
It is possible to force a specific version of python to be used when building the kernel by passing PYTHON3= on the make command line. However kernel-doc.py is currently called with python3 hard-coded and thus ignores this setting. Use $(PYTHON3) to run $(KERNELDOC) so that the desired version of python is used. Signed-off-by: Jean Delvare <jdelvare@suse.de> Reviewed-by: Nicolas Schier <nsc@kernel.org> Reviewed-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Link: https://patch.msgid.link/20251107192933.2bfe9e57@endymion Signed-off-by: Nathan Chancellor <nathan@kernel.org>
2025-11-08kbuild: Rename Makefile.extrawarn to Makefile.warnNathan Chancellor
Since commit e88ca24319e4 ("kbuild: consolidate warning flags in scripts/Makefile.extrawarn"), scripts/Makefile.extrawarn contains all warnings for the main kernel build, not just warnings enabled by the values for W=. Rename it to scripts/Makefile.warn to make it clearer that this Makefile is where all Kbuild warning handling should exist. Signed-off-by: Nathan Chancellor <nathan@kernel.org> Acked-by: Arnd Bergmann <arnd@arndb.de> Link: https://patch.msgid.link/20251023-rename-scripts-makefile-extrawarn-v1-1-8f7531542169@kernel.org Signed-off-by: Nicolas Schier <nsc@kernel.org>
2025-11-08Revert "drm/nouveau: set DMA mask before creating the flush page"Dave Airlie
This reverts commit ebe755605082eddff80eafe0c50915b1366ee98f. Tested the latest kernel on my GB203 and this seems to break it somehow. Nov 09 04:16:14 bighp kernel: nouveau 0000:02:00.0: gsp: GSP-FMC boot failed (mbox: 0x0000000b) Nov 09 04:16:14 bighp kernel: nouveau 0000:02:00.0: gsp: init failed, -5 Nov 09 04:16:14 bighp kernel: nouveau 0000:02:00.0: init failed with -5 Nov 09 04:16:14 bighp kernel: nouveau: drm:00000000:00000080: init failed with -5 Nov 09 04:16:14 bighp kernel: nouveau 0000:02:00.0: drm: Device allocation failed: -5 Nov 09 04:16:14 bighp kernel: nouveau 0000:02:00.0: probe with driver nouveau failed with error -5 Not sure why, I went over the patch and thought it should have worked, but there must be some 32-bit problem maybe in the FMC boot path. Signed-off-by: Dave Airlie <airlied@redhat.com>
2025-11-08gpu: nova-core: justify remaining uses of `as`Alexandre Courbot
There are a few remaining cases where we *do* want to use `as`, because we specifically want to strip the data that does not fit into the destination type. Comment these uses to clear confusion about the intent. Acked-by: Danilo Krummrich <dakr@kernel.org> [acourbot@nvidia.com: fix merge conflicts after rebase.] Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Message-ID: <20251029-nova-as-v3-6-6a30c7333ad9@nvidia.com>
2025-11-08gpu: nova-core: replace use of `as` with functions from `num`Alexandre Courbot
Use the newly-introduced `num` module to replace the use of `as` wherever it is safe to do. This ensures that a given conversion cannot lose data if its source or destination type ever changes. Acked-by: Danilo Krummrich <dakr@kernel.org> [acourbot@nvidia.com: fix merge conflicts after rebase.] Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Message-ID: <20251029-nova-as-v3-5-6a30c7333ad9@nvidia.com>
2025-11-08gpu: nova-core: add functions and traits for lossless integer conversionsAlexandre Courbot
The core library's `From` implementations do not cover conversions that are not portable or future-proof. For instance, even though it is safe today, `From<usize>` is not implemented for `u64` because of the possibility to support larger-than-64bit architectures in the future. However, the kernel supports a narrower set of architectures, and in the case of Nova we only support 64-bit. This makes it helpful and desirable to provide more infallible conversions, lest we need to rely on the `as` keyword and carry the risk of silently losing data. Thus, introduce a new module `num` that provides safe const functions performing more conversions allowed by the build target, as well as `FromSafeCast` and `IntoSafeCast` traits that are just extensions of `From` and `Into` to conversions that are known to be lossless. Suggested-by: Danilo Krummrich <dakr@kernel.org> Link: https://lore.kernel.org/rust-for-linux/DDK4KADWJHMG.1FUPL3SDR26XF@kernel.org/ Acked-by: Danilo Krummrich <dakr@kernel.org> [acourbot@nvidia.com: fix merge conflicts after rebase.] Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Message-ID: <20251029-nova-as-v3-4-6a30c7333ad9@nvidia.com>
2025-11-08Merge tag 'drm-xe-fixes-2025-11-07' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/xe/kernel into drm-fixes Driver Changes: - Fix missing synchronization on unbind (Balasubramani Vivekanandan) - Fix device shutdown when doing FLR (Jouni Högander) - Fix user fence signaling order (Matthew Brost) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patch.msgid.link/mvfyflloncy76a7nmkatpj6f2afddavwsibz3y4u4wo6gznro5@rdulkuh5wvje
2025-11-07drm/xe/tests: Add KUnit tests for PF fair provisioningMichal Wajdeczko
Add test cases to check outcome of fair GuC context or doorbells IDs allocations for regular and admin-only PF mode. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Link: https://patch.msgid.link/20251106165932.2143-1-michal.wajdeczko@intel.com
2025-11-07drm/xe/pf: Use migration-friendly doorbells auto-provisioningMichal Wajdeczko
Instead of trying very hard to find the largest fair number of GuC doorbell IDs that could be allocated for VFs on the current GT, pick some smaller rounded down to power-of-two value that is more likely to be provisioned in the same manner by the other PF instance: num VFs | num doorbells --------+-------------- 63..32 | 4 31..16 | 8 15..8 | 16 7..4 | 32 3..2 | 64 1 | 128 (regular PF) 1 | 240 (admin only PF) Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Link: https://patch.msgid.link/20251105183253.863-3-michal.wajdeczko@intel.com
2025-11-07drm/xe/pf: Use migration-friendly context IDs auto-provisioningMichal Wajdeczko
Instead of trying very hard to find the largest fair number of GuC context IDs that could be allocated for VFs on the current GT, pick some smaller rounded down to power-of-two value that is more likely to be provisioned in the same manner by the other PF instance: num VFs | num contexts --------+------------- 63..32 | 1024 31..16 | 2048 15..8 | 4096 7..4 | 8192 3..2 | 16384 1 | 32768 (regular PF) 1 | 64512 (admin only PF) Add also helper function to determine if the PF is admin-only, and for now use .probe_display flag for that. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Link: https://patch.msgid.link/20251105183253.863-2-michal.wajdeczko@intel.com
2025-11-07drm/i915/pmdemand: Use the default 2 usec fast polling timeoutVille Syrjälä
For whatever unknown reason the pmdemand code is using a custom 50 usec fast polling timeout instead of the normal 2 usec value. Switch to the standard value to get rid of the special case. The eventual aim is to get rid of the fast vs. slow timeout entirely and switch over to poll_timeout_us(). Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251106152049.21115-11-ville.syrjala@linux.intel.com
2025-11-07drm/i915/hdcp: Use the default 2 usec fast polling timeoutVille Syrjälä
For whatever unknown reason the HDCP code is using a custom 10 usec fast polling timeout instead of the normal 2 usec value. Switch to the standard value to get rid of the special case. The eventual aim is to get rid of the fast vs. slow timeout entirely and switch over to poll_timeout_us(). Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251106152049.21115-10-ville.syrjala@linux.intel.com
2025-11-07drm/i915/ltphy: Nuke bogus weird timeoutsVille Syrjälä
The LT PHY code is abusing intel_de_wait_custom() in all kinds of weird ways. Get rid of the weird fast timeouts, and just use the slow ones. For consistency with intel_wait_for_register() we'll stick to the default 2 usec fast timeout for all cases. Someone really needs to properly document where all these magic numbers came from... This will let us eventually nuke intel_de_wait_custom() and convert over to poll_timeout_us(). v2: Go for the longer (ms) timeout in case it actually matters Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251106152049.21115-9-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-11-07drm/i915/cx0: s/XELPDP_PORT_RESET_END_TIMEOUT/XELPDP_PORT_RESET_END_TIMEOUT_MS/Ville Syrjälä
Include the units the in the define name for XELPDP_PORT_RESET_END_TIMEOUT to make it match all its other counterparts. v2: It's _MS not _US (Jani) Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251106155249.2810-1-ville.syrjala@linux.intel.com
2025-11-07drm/i915/cx0: s/XELPDP_MSGBUS_TIMEOUT_SLOW/XELPDP_MSGBUS_TIMEOUT_MS/Ville Syrjälä
The slow vs. fast timeout stuff is really just an implementation detail. Let's not spread that terminology in random timeout defines. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251106152049.21115-7-ville.syrjala@linux.intel.com
2025-11-07drm/i915/cx0: Get rid of XELPDP_MSGBUS_TIMEOUT_FAST_USVille Syrjälä
XELPDP_MSGBUS_TIMEOUT_FAST_US looks to be just an obfuscated version of the default 2 microsecond fast timeout used by intel_wait_for_register(). Get rid of it to make it clear what's going on here. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251106152049.21115-6-ville.syrjala@linux.intel.com
2025-11-07drm/i915/cx0: Replace XELPDP_PORT_POWERDOWN_UPDATE_TIMEOUT_US with ↵Ville Syrjälä
XELPDP_PORT_POWERDOWN_UPDATE_TIMEOUT_MS There was a completely unjustified change to the cx0 powerdown timeout, and the way it was done now prevents future conversion to poll_timeout_us(). Assuming there was some reason the bigger timeout let's nuke the old short timeout (XELPDP_PORT_POWERDOWN_UPDATE_TIMEOUT_US) nd replace it with the bigger timeout (XELPDP_PORT_POWERDOWN_UPDATE_TIMEOUT_MS). For consistency with intel_wait_for_register() we'll stick to the default 2 usec for the fast timeout. v2: Go for the longer (ms) timeout in case it actually matters v3: Note the defaullt 2 usec fast timeout (Jani) Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251106152049.21115-5-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-11-07drm/i915/ltphy: Nuke extraneous timeout debugsVille Syrjälä
The actual timeout used isn't particularly interesting, so don't print it. Makes the code simpler. The debugs are also using some random capitalizaton rule. Clean that up a bit while at it. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251106152049.21115-4-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-11-07drm/i915/cx0: Nuke extraneous timeout debugsVille Syrjälä
The actual timeout used isn't particularly interesting, so don't print it. Makes the code simpler. The debugs are also using some random capitalizaton rule. Clean that up a bit while at it. Also intel_cx0_powerdown_change_sequence() used one timeout in the actual code but printed a different one. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251106152049.21115-3-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-11-07drm/i915/gem: ↵Ville Syrjälä
s/i915_gem_object_get_frontbuffer/i915_gem_object_frontbuffer_lookup/ The i915_gem_object_get_frontbuffer() name is rather confusing wrt. intel_frontbuffer_get(). Rename to i915_gem_object_frontbuffer_lookup() to make things less confusing. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251016185408.22735-11-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-11-07drm/i915/frontbuffer: Fix intel_frontbuffer lifetime handlingVille Syrjälä
The current attempted split between xe/i915 vs. display for intel_frontbuffer is a mess: - the i915 rcu leaks through the interface to the display side - the obj->frontbuffer write-side is now protected by a display specific spinlock even though the actual obj->framebuffer pointer lives in a i915 specific structure - the kref is getting poked directly from both sides - i915_active is still on the display side Clean up the mess by moving everything about the frontbuffer lifetime management to the i915/xe side: - the rcu usage is now completely contained in i915 - frontbuffer_lock is moved into i915 - kref is on the i915/xe side (xe needs the refcount as well due to intel_frontbuffer_queue_flush()->intel_frontbuffer_ref()) - the bo (and its refcounting) is no longer on the display side - i915_active is contained in i915 I was pondering whether we could do this in some kind of smaller steps, and perhaps we could, but it would probably have to start with a bunch of reverts (which for sure won't go cleanly anymore). So not convinced it's worth the hassle. Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251016185408.22735-10-ville.syrjala@linux.intel.com
2025-11-07drm/i915/frontbuffer: Add intel_frontbuffer::displayVille Syrjälä
After upcoming intel_frontbuffer lifetime related changes we won't need intel_frontbuffer::obj for anything apart from getting at the display. Add a direct pointer for that instead so that the obj pointer can be completely eliminated. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251016185408.22735-9-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-11-07drm/i915/frontbuffer: Extract intel_frontbuffer_ref()Ville Syrjälä
I want to hide the kref from the high level frontbuffer code. To that end abstract the kref_get() in intel_frontbuffer_queue_flush() (which is the only high level function that needs this) as a new intel_frontbuffer_ref(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251016185408.22735-8-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-11-07drm/i915/frontbuffer: Split fb_tracking.lock into twoVille Syrjälä
Our fb_tracking.lock is serving a double duty: - protects fb_tracking.busy_bits - provides the write-side protection for obj->frontbuffer Split obj->frontbuffer role into a separate lock so that we can clean up the current mess with the frontbuffer lifetime management. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251016185408.22735-7-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-11-07drm/i915/frontbuffer: Handle the dirtyfb cache flush inside ↵Ville Syrjälä
intel_frontbuffer_flush() intel_bo_frontbuffer_flush_for_display() is a bit too low level to be directly in the high level dirtyfb code. Move the calls into intel_frontbuffer_flush(). There is a slight behavioural change here in that we now skip the flush if the bo is not a current scanout buffer (front->bits == 0). But that is fine as the flush will eventually happen via the fb pinning code if/when the bo becomes a scanout buffer again. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251016185408.22735-6-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-11-07drm/i915/frontbuffer: Turn intel_bo_flush_if_display() into a frontbuffer ↵Ville Syrjälä
operation Convert intel_bo_flush_if_display() to be an operation on the frontbuffer object rather than the underlying gem bo. This will help with cleaning up the frontbuffer xe/i915 vs. display split. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251016185408.22735-5-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-11-07drm/i915/frontbuffer: Nuke intel_frontbuffer_flip_{prepare,complete}()Ville Syrjälä
Get rid of intel_frontbuffer_flip_{prepare,complete}() (and the accompanying flip_bits) since they are unused. I suppose these could technically provide a minor optimization over intel_frontbuffer_flip() in that the flush would get deferred further if new rendering were to sneak in between the prepare() and complete() calls. But for correctness it should not make any difference since another flush will anyway follow once the new rendering finishes. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251016185408.22735-4-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-11-07drm/i915/overlay: Switch to intel_frontbuffer_flip()Ville Syrjälä
Get rid of intel_frontbuffer_flip_{prepare,complete}() from the overlay code and just use intel_frontbuffer_flip() instead. The only difference between these are the light interactions with the ORIGIN_CS busyness tracking, but since the only user of this is the overlay/xf86-video-intel/Xv the buffer will always be filled by the CPU and thus we'll never see any ORIGIN_CS frontbuffer activity there anyway. Also I don't think we actually have anything covered by the frontbuffer tracking that affects the overlay (FBC is on the primary plane, DRRS isn't currently enabled on the platforms with overlay, and PSR doesn't exist in the hardware). Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251016185408.22735-3-ville.syrjala@linux.intel.com
2025-11-07drm/i915/overlay: Drop the DIRTYFB flushVille Syrjälä
I don't even know why we have this DIRTYFB flush in the overlay code. We'll anyway call intel_frontbuffer_flip() so there should be no need to pretend that this is some kind of frontbuffer only rendering operation. Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251016185408.22735-2-ville.syrjala@linux.intel.com
2025-11-07gpu: nova-core: Simplify `DmaObject::from_data` in nova-core/dma.rsDaniel del Castillo
This patch solves one of the existing mentions of COHA, a task in the Nova task list about improving the `CoherentAllocation` API. It uses the `write` method from `CoherentAllocation`. Signed-off-by: Daniel del Castillo <delcastillodelarosadaniel@gmail.com> [acourbot@nvidia.com: set prefix to "gpu: nova-core:".] Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Message-ID: <20251104193756.57726-3-delcastillodelarosadaniel@gmail.com>
2025-11-07gpu: nova-core: Fix capitalization of some commentsDaniel del Castillo
Some comments that already existed didn't start with a capital letter, this patch fixes that. Signed-off-by: Daniel del Castillo <delcastillodelarosadaniel@gmail.com> [acourbot@nvidia.com: set prefix to "gpu: nova-core:".] Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Message-ID: <20251104193756.57726-2-delcastillodelarosadaniel@gmail.com>
2025-11-07gpu: nova-core: Simplify `transmute` and `transmute_mut` in fwsec.rsDaniel del Castillo
This patch solves one of the existing mentions of COHA, a task in the Nova task list about improving the `CoherentAllocation` API. It uses the new `from_bytes` method from the `FromBytes` trait as well as the `as_slice` and `as_slice_mut` methods from `CoherentAllocation`. Signed-off-by: Daniel del Castillo <delcastillodelarosadaniel@gmail.com> [acourbot@nvidia.com: set prefix to "gpu: nova-core:".] [acourbot@nvidia.com: fix merge conflict after imports refactor.] Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Message-ID: <20251104193756.57726-1-delcastillodelarosadaniel@gmail.com>
2025-11-07gpu: nova-core: apply the one "use" item per line policyJohn Hubbard
As per [1], we need one "use" item per line, in order to reduce merge conflicts. Furthermore, we need a trailing ", //" in order to tell rustfmt(1) to leave it alone. This does that for the entire nova-core driver. [1] https://docs.kernel.org/rust/coding-guidelines.html#imports Acked-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: John Hubbard <jhubbard@nvidia.com> [acourbot@nvidia.com: remove imports already in prelude as pointed out by Danilo.] [acourbot@nvidia.com: remove a few unneeded trailing `//`.] Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Message-ID: <20251107021006.434109-1-jhubbard@nvidia.com>
2025-11-07drm/i915/psr: fix pipe to vblank conversionJani Nikula
First, we can't assume pipe == crtc index. If a pipe is fused off in between, it no longer holds. intel_crtc_for_pipe() is the only proper way to get from a pipe to the corresponding crtc. Second, drivers aren't supposed to access or index drm->vblank[] directly. There's drm_crtc_vblank_crtc() for this. Use both functions to fix the pipe to vblank conversion. Fixes: f02658c46cf7 ("drm/i915/psr: Add mechanism to notify PSR of pipe enable/disable") Cc: Jouni Högander <jouni.hogander@intel.com> Cc: stable@vger.kernel.org # v6.16+ Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patch.msgid.link/20251106200000.1455164-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-11-07drm/xe: Enforce correct user fence signaling order usingMatthew Brost
Prevent application hangs caused by out-of-order fence signaling when user fences are attached. Use drm_syncobj (via dma-fence-chain) to guarantee that each user fence signals in order, regardless of the signaling order of the attached fences. Ensure user fence writebacks to user space occur in the correct sequence. v7: - Skip drm_syncbj create of error (CI) Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Link: https://patch.msgid.link/20251031234050.3043507-2-matthew.brost@intel.com (cherry picked from commit adda4e855ab6409a3edaa585293f1f2069ab7299) Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-11-07drm/xe: Do clean shutdown also when using flrJouni Högander
Currently Xe driver is triggering flr without any clean-up on shutdown. This is causing random warnings from pending related works as the underlying hardware is reset in the middle of their execution. Fix this by performing clean shutdown also when using flr. Fixes: 501d799a47e2 ("drm/xe: Wire up device shutdown handler") Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Maarten Lankhorst <dev@lankhorst.se> Link: https://patch.msgid.link/20251031122312.1836534-1-jouni.hogander@intel.com Signed-off-by: Maarten Lankhorst <dev@lankhorst.se> (cherry picked from commit a4ff26b7c8ef38e4dd34f77cbcd73576fdde6dd4) Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-11-07drm/xe: Move declarations under conditional branchTejas Upadhyay
The xe_device_shutdown() function was needing a few declarations that were only required under a specific condition. This change moves those declarations to be within that conditional branch to avoid unnecessary declarations. Reviewed-by: Nitin Gote <nitin.r.gote@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20251007100208.1407021-1-tejas.upadhyay@intel.com Signed-off-by: Tejas Upadhyay <tejas.upadhyay@intel.com> (cherry picked from commit 15b3036045188f4da4ca62b2ed01b0f160252e9b) Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-11-07drm/xe/guc: Synchronize Dead CT worker with unbindBalasubramani Vivekanandan
Cancel and wait for any Dead CT worker to complete before continuing with device unbinding. Else the worker will end up using resources freed by the undind operation. Cc: Zhanjun Dong <zhanjun.dong@intel.com> Fixes: d2c5a5a926f4 ("drm/xe/guc: Dead CT helper") Signed-off-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Reviewed-by: Stuart Summers <stuart.summers@intel.com> Link: https://patch.msgid.link/20251103123144.3231829-6-balasubramani.vivekanandan@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> (cherry picked from commit 492671339114e376aaa38626d637a2751cdef263) Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-11-07drm/vmwgfx: Set surface-framebuffer GEM objectsThomas Zimmermann
Set struct drm_framebuffer.obj[0] to the allocated GEM buffer object for surface framebuffers. Avoids a NULL-pointer deref in the client's vmap helpers. [ 22.640191] Console: switching to colour frame buffer device 160x50 [ 22.641788] Oops: general protection fault, probably for non-canonical address 0xdffffc000000001f: 0000 [#1] SMP KASAN NOPTI [ 22.641795] KASAN: null-ptr-deref in range [0x00000000000000f8-0x00000000000000ff] [...] [ 22.641809] Hardware name: VMware, Inc. VMware20,1/440BX Desktop Reference Platform, BIOS VMW201.00V.24928539.B64.2508260915 08/26/2025 [ 22.641812] Workqueue: events drm_fb_helper_damage_work [ 22.641824] RIP: 0010:drm_gem_lock+0x25/0x50 [ 22.641831] Code: 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 48 b8 00 00 00 00 00 fc ff df 53 48 89 fb 48 81 c7 f8 00 00 00 48 89 fa 48 c1 ea 03 <80> 3c 02 00 75 0f 48 8b bb f8 00 00 00 31 f6 5b e9 16 2e 15 01 e8 [...] [ 22.641889] Call Trace: [ 22.641891] <TASK> [ 22.641894] drm_client_buffer_vmap_local+0x78/0x140 [ 22.641903] drm_fbdev_ttm_helper_fb_dirty+0x20c/0x510 [drm_ttm_helper] [ 22.641913] ? __pfx_drm_fbdev_ttm_helper_fb_dirty+0x10/0x10 [drm_ttm_helper] [ 22.641918] ? __raw_spin_lock_irqsave+0x8c/0xf0 [ 22.641924] ? __pfx___raw_spin_lock_irqsave+0x10/0x10 [ 22.641928] ? __pfx_mutex_lock+0x10/0x10 [ 22.641936] drm_fb_helper_fb_dirty+0x29a/0x5e0 [ 22.641942] ? __pfx_drm_fb_helper_fb_dirty+0x10/0x10 [...] Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Fixes: ea39f2e66e61 ("drm/client: Deprecate struct drm_client_buffer.gem") Reported-by: Ian Forbes <ian.forbes@broadcom.com> Closes: https://lore.kernel.org/dri-devel/CAO6MGtjg8PiRiSLomJQRBduTBSC0WkqX67tEZwA9qwOgRzchpw@mail.gmail.com/ Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Jocelyn Falempe <jfalempe@redhat.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: David Airlie <airlied@gmail.com> Cc: Simona Vetter <simona@ffwll.ch> Cc: dri-devel@lists.freedesktop.org Tested-by: Ian Forbes <ian.forbes@broadcom.com> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Reviewed-by: Zack Rusin <zack.rusin@broadcom.com> Link: https://patch.msgid.link/20251104103611.167821-1-tzimmermann@suse.de
2025-11-07drm/vblank: Increase timeout in drm_wait_one_vblank()Chintan Patel
Currently, wait_event_timeout() in drm_wait_one_vblank() uses a 100ms timeout. Under heavy scheduling pressure or rare delayed vblank handling, this can trigger WARNs unnecessarily. Increase the timeout to 1000ms to reduce spurious WARNs, while still catching genuine issues. Reported-by: syzbot+147ba789658184f0ce04@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=147ba789658184f0ce04 Tested-by: syzbot+147ba789658184f0ce04@syzkaller.appspotmail.com Signed-off-by: Chintan Patel <chintanlike@gmail.com> v2: - Dropped unnecessary in-code comment (suggested by Thomas Zimmermann) - Removed else branch, only log timeout case v3: - Replaced drm_dbg_kms()/manual logging with drm_err() (suggested by Ville Syrjälä) - Removed unnecessary curr = drm_vblank_count() (suggested by Thomas Zimmermann) - Fixed commit message wording ("invalid userspace calls" → "delayed vblank handling") v4: - Keep the original drm_WARN() to catch genuine kernel issues - Increased timeout from 100ms → 1000ms to reduce spurious WARNs (suggested by Thomas Zimmermann) Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20251028034337.6341-1-chintanlike@gmail.com
2025-11-07drm/vblank: Fix kernel docs for vblank timerThomas Zimmermann
Fix documentation for drm_crtc_vblank_start_timer(), which referred to drm_crtc_vblank_cancel_timer(). Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Closes: https://lore.kernel.org/dri-devel/20251106152201.6f248c09@canb.auug.org.au/ Fixes: 74afeb812850 ("drm/vblank: Add vblank timer") Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Louis Chauvet <louis.chauvet@bootlin.com> Cc: Javier Martinez Canillas <javierm@redhat.com> Cc: David Airlie <airlied@gmail.com> Cc: Simona Vetter <simona@ffwll.ch> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: dri-devel@lists.freedesktop.org Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com> Link: https://patch.msgid.link/20251106073207.11192-1-tzimmermann@suse.de
generated by cgit v1.2.3 (git 2.25.1) at 2026-01-25 00:48:38 +0000