mirrors/linux
2
0
Fork 0
mirror of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git synced 2026-08-05 19:04:32 -04:00
Code Issues Packages Projects Releases Wiki Activity
1,429,592 Commits 1 Branch 941 Tags
d78ddeb8938a366aabfabf60255c1a94de8d8ea1
Commit Graph

122554 Commits

Author SHA1 Message Date
Michal Wajdeczko
3764e9b99f drm/xe/pf: Fix VF FLR synchronization between all GTs 
If subsequent VF FLR request is triggered when previous VF FLR
sequence is still being processed, we ignore it as not needed.

But in case of the multi-GT platforms, one GT may already finish
its VF FLR processing and will start a new sequence, which includes
new cross-GT synchronization point.  However, since other GT may
be still busy with post-sync cleanup steps, this will put on hold
this new FLR sequence, which might never finish due to lack of any
future synchronization checkouts.

Add additional cross-GT FLR synchronization point when each GT
ends processing its own FLR sequence.  This should also help to
cover the case when one GT fails FLR processing before reaching
the first synchronization point.

Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/6287
Fixes: 2a8fcf7cc9 ("drm/xe/pf: Synchronize VF FLR between all GTs")
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com>
Link: https://patch.msgid.link/20251025124906.5264-1-michal.wajdeczko@intel.com
 2025-10-27 15:23:32 +01:00
Sanjay Yadav
dd5d11b657 drm/xe: Fix spelling and typos across Xe driver files 
Corrected various spelling mistakes and typos in multiple
files under the Xe directory. These fixes improve clarity
and maintain consistency in documentation.

v2
- Replaced all instances of "XE" with "Xe" where it referred
  to the driver name
- of -> for
- Typical -> Typically

v3
- Revert "Xe" to "XE" for macro prefix reference

Signed-off-by: Sanjay Yadav <sanjay.kumar.yadav@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Stuart Summers <stuart.summers@intel.com>
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patch.msgid.link/20251023121453.1182035-2-sanjay.kumar.yadav@intel.com
 2025-10-27 13:00:11 +00:00
Philipp Stanner
e0023c8a74 drm/nouveau: Fix race in nouveau_sched_fini() 
nouveau_sched_fini() uses a memory barrier before wait_event().
wait_event(), however, is a macro which expands to a loop which might
check the passed condition several times. The barrier would only take
effect for the first check.

Replace the barrier with a function which takes the spinlock.

Cc: stable@vger.kernel.org # v6.8+
Fixes: 5f03a507b2 ("drm/nouveau: implement 1:1 scheduler - entity relationship")
Acked-by: Danilo Krummrich <dakr@kernel.org>
Signed-off-by: Philipp Stanner <phasta@kernel.org>
Link: https://patch.msgid.link/20251024161221.196155-2-phasta@kernel.org
 2025-10-27 13:58:56 +01:00
Philipp Stanner
d25e3a610b drm/sched: Fix race in drm_sched_entity_select_rq() 
In a past bug fix it was forgotten that entity access must be protected
by the entity lock. That's a data race and potentially UB.

Move the spin_unlock() to the appropriate position.

Cc: stable@vger.kernel.org # v5.13+
Fixes: ac4eb83ab2 ("drm/sched: select new rq even if there is only one v3")
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
Signed-off-by: Philipp Stanner <phasta@kernel.org>
Link: https://patch.msgid.link/20251022063402.87318-2-phasta@kernel.org
 2025-10-27 13:48:46 +01:00
Greg Kroah-Hartman
37022410f4 Merge 6.18-rc3 into driver-core-next 
We need the driver core fixes in here as well to build on top of.

Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
 2025-10-27 08:02:50 +01:00
Thomas Zimmermann
9837f9fcb7 drm/gem-atomic: Reset plane state to NULL if allocation failed 
Unconditionally reset plane->state to NULL if the allocation of the
shadow plane state fails. Avoids an invalid address in the field.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://patch.msgid.link/20251017091919.58770-1-tzimmermann@suse.de
 2025-10-26 17:12:58 +01:00
Thomas Zimmermann
14e02ed387 drm/sysfb: Do not dereference NULL pointer in plane reset 
The plane state in __drm_gem_reset_shadow_plane() can be NULL. Do not
deref that pointer, but forward NULL to the other plane-reset helpers.
Clears plane->state to NULL.

v2:
- fix typo in commit description (Javier)

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Fixes: b715650220 ("drm/gem: Export implementation of shadow-plane helpers")
Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
Closes: https://lore.kernel.org/dri-devel/aPIDAsHIUHp_qSW4@stanley.mountain/
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Melissa Wen <melissa.srw@gmail.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
Cc: <stable@vger.kernel.org> # v5.15+
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://patch.msgid.link/20251017091407.58488-1-tzimmermann@suse.de
 2025-10-26 17:09:56 +01:00
Rob Clark
00d5f09719 drm/msm: Ensure vm is created in VM_BIND ioctl 
Since the vm is lazily created, to allow userspace to opt-in to a
VM_BIND context, we can't assume it is already created.

Fixes: 2e6a8a1fe2 ("drm/msm: Add VM_BIND ioctl")
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/682939/
Message-ID: <20251022222039.9937-1-robin.clark@oss.qualcomm.com>
 2025-10-25 10:01:11 -07:00
Rob Clark
73b7e48a87 drm/msm: Reject MAP_NULL op if no PRR 
We need PRR support in order to implement MAP_NULL.  Userspace shouldn't
be trying to use this if it is unsupported.

Reported-by: Valentine Burley <valentine.burley@collabora.com>
Link: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37935#note_3153730
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
Tested-by: Valentine Burley <valentine.burley@collabora.com>
Patchwork: https://patchwork.freedesktop.org/patch/682941/
Message-ID: <20251022222051.10030-1-robin.clark@oss.qualcomm.com>
 2025-10-25 10:01:03 -07:00
Alexandre Courbot
ca16b15e78 gpu: nova-core: bitfield: remove BitOr implementation 
Using this operand can produce invalid values. It also doesn't bring
any benefit as one can use the builder pattern to assemble a new value.

Reported-by: Edwin Peer <epeer@nvidia.com>
Link: https://lore.kernel.org/rust-for-linux/F3853912-2C1C-4F9B-89B0-3168689F35B3@nvidia.com/
Reviewed-by: Joel Fernandes <joelagnelf@nvidia.com>
Reviewed-by: Danilo Krummrich <dakr@kernel.org>
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Message-ID: <20251022-nova-bitfield-v1-3-73bc0988667b@nvidia.com>
 2025-10-25 13:16:31 +09:00
Alexandre Courbot
e6b8932b93 gpu: nova-core: bitfield: simplify expression 
The shift is more easily expressed by the index of the lowest bit of the
field.

Reported-by: Edwin Peer <epeer@nvidia.com>
Link: https://lore.kernel.org/rust-for-linux/F3853912-2C1C-4F9B-89B0-3168689F35B3@nvidia.com/
Reviewed-by: Joel Fernandes <joelagnelf@nvidia.com>
Reviewed-by: Danilo Krummrich <dakr@kernel.org>
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Message-ID: <20251022-nova-bitfield-v1-2-73bc0988667b@nvidia.com>
 2025-10-25 13:16:31 +09:00
Alexandre Courbot
fa08ec789f gpu: nova-core: bitfield: simplify condition 
This condition was uselessly convoluted.

Reported-by: Edwin Peer <epeer@nvidia.com>
Link: https://lore.kernel.org/rust-for-linux/F3853912-2C1C-4F9B-89B0-3168689F35B3@nvidia.com/
Reviewed-by: Joel Fernandes <joelagnelf@nvidia.com>
Reviewed-by: Danilo Krummrich <dakr@kernel.org>
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Message-ID: <20251022-nova-bitfield-v1-1-73bc0988667b@nvidia.com>
 2025-10-25 13:16:31 +09:00
Alexandre Courbot
76544ef6a0 gpu: nova-core: replace wait_on with kernel equivalents 
wait_on was a temporary helper function waiting for a kernel crate
equivalent.

Now that read_poll_timeout and fsleep are available, use them and remove
wait_on.

Acked-by: Danilo Krummrich <dakr@kernel.org>
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Message-ID: <20251020-nova_wait_on-v1-1-2eb87fb38d14@nvidia.com>
 2025-10-25 13:14:21 +09:00
John Hubbard
c58f00b44e gpu: nova-core: remove unnecessary need_riscv, bar parameters 
The need_riscv parameter and its associated RISCV validation logic are
are actually unnecessary for correct operation. Remove it, along with
the now-unused bar parameter as well.

Signed-off-by: John Hubbard <jhubbard@nvidia.com>
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Message-ID: <20251025014050.585153-3-jhubbard@nvidia.com>
 2025-10-25 13:12:05 +09:00
John Hubbard
1784fb79d6 gpu: nova-core: remove an unnecessary register read: HWCFG1 
This register read is not required in order to bring up any of the GPUs,
and it is read too early on Hopper/Blackwell+ GPUs anyway. So just stop
doing this.

Signed-off-by: John Hubbard <jhubbard@nvidia.com>
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Message-ID: <20251025014050.585153-2-jhubbard@nvidia.com>
 2025-10-25 13:12:05 +09:00
John Hubbard
f6797dca29 gpu: nova-core: Ada: basic GPU identification 
...which is sufficient to make Ada GPUs work, because they use the
pre-existing Ampere GPU code, unmodified.

Tested on AD102 (RTX 6000 Ada).

Signed-off-by: John Hubbard <jhubbard@nvidia.com>
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Message-ID: <20251025012017.573078-1-jhubbard@nvidia.com>
 2025-10-25 13:12:05 +09:00
John Hubbard
34aadecdf3 gpu: nova-core: regs: rename .alter() --> .update() 
This also changes .try_alter() to try_update().

After this commit, instead of "read, write and alter", the methods
available for registers are now "read, write and update".

This reads a lot easier for people who are used to working with
registers, and aligns the API with what e.g. regmap uses.

No functional changes are intended.

Signed-off-by: John Hubbard <jhubbard@nvidia.com>
[acourbot@nvidia.com: add Link tag for context.]
[acourbot@nvidida.com: mention regmap in commit log.]
Link: https://lore.kernel.org/all/2c5d90c8-e73a-4f04-9c1d-30adbd0fef07@nvidia.com/
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Message-ID: <20251025010815.566909-2-jhubbard@nvidia.com>
 2025-10-25 13:12:02 +09:00
Matt Roper
fab36494f2 drm/xe/configfs: Drop MAX_GT_TYPE_CHARS constant 
Early revisions of commit 7abd69278b ("drm/xe/configfs: Add attribute
to disable GT types") used MAX_GT_TYPE_CHARS not only to size the
constant name field, but also for some of the string matching logic.  By
the time the patch finally landed, the constant was no longer needed for
parsing.  Stop using it for the string field definition as well; this
eliminates the risk that we forget to update the constant if we ever add
a GT type name longer than seven characters.

Suggested-by: Gustavo Sousa <gustavo.sousa@intel.com>
Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patch.msgid.link/20251024200834.1512329-2-matthew.d.roper@intel.com
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
 2025-10-24 15:00:38 -07:00
Ville Syrjälä
4b274b0b61 drm/i915/vrr: Check HAS_VRR() first in intel_vrr_is_capable() 
There's no point in doing all the other checks in
intel_vrr_is_capable() if the platform doesn't support VRR at all
Check HAS_VRR() before wasting time on the other checks.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20251020185038.4272-23-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
 2025-10-25 00:10:58 +03:00
Ville Syrjälä
be5fc552b3 drm/i915/vrr: Update the intel_vrr_extra_vblank_delay() comment 
The coment in intel_vrr_extra_vblank_delay() is a bit outdated now
that we generally got rid of the "vblank delay" stuff. Update the
comment to better describe the current state of things.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20251020185038.4272-22-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
 2025-10-25 00:10:58 +03:00
Ville Syrjälä
0f4f31d79e drm/i915/vrr: Nuke intel_vrr_vmin_flipline() 
Now that intel_vrr_flipline_offset() is completely hidden from the
higher level VRR code, intel_vrr_vmin_flipline() has become rather
pointless. Remove it.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20251020185038.4272-21-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
 2025-10-25 00:10:58 +03:00
Ville Syrjälä
24a23b39fd drm/i915/vrr: Nuke intel_vrr_vblank_exit_length() 
Now that we always populate crtc_state->vrr.guardband even on
ICL/TGL intel_vrr_vblank_exit_length() has become rather pointless.
Get rid of it.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20251020185038.4272-20-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
 2025-10-25 00:10:58 +03:00
Ville Syrjälä
cbdf2a930b drm/i915/vrr: s/crtc_state/old_crtc_state/ in intel_vrr_transcoder_disable() 
We generally use the 'old_crtc_state' in the disable functions to
make it clear these generally get called when the hardware is
still using the old crtc state rather than the new crtc state.
Rename the intel_vrr_transcoder_disable() 'crtc_state' parameter
to 'old_crtc_state' for consistency.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20251020185038.4272-19-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
 2025-10-25 00:10:58 +03:00
Ville Syrjälä
78ea8eb5b6 drm/i915/vrr: Move HAS_VRR() check into intel_vrr_set_transcoder_timings() 
Reduce the clutter in hsw_configure_cpu_transcoder() a bit by moving
the HAS_VRR() check into intel_vrr_set_transcoder_timings().

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20251020185038.4272-18-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
 2025-10-25 00:10:58 +03:00
Ville Syrjälä
065d28dd32 drm/i915/vrr: Remove redundant HAS_VRR() checks 
intel_vrr_transcoder_{enable,disable}() already check
for intel_vrr_possible(), so the extra HAS_VRR() checks are
redundant. Remove them.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20251020185038.4272-17-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
 2025-10-25 00:10:58 +03:00
Ville Syrjälä
9a78c6dfd1 drm/i915/vrr: Always write TRANS_VRR_CTL in intel_vrr_set_transcoder_timings() on !always_use_vrr_tg() 
Currently, depending on vrr.enable, we may write TRANS_VRR_CTL from
both intel_vrr_set_transcoder_timings() and intel_vrr_transcoder_enable()
on !always_use_vrr_tg() platforms. Streamline this so that we just
always write it from intel_vrr_set_transcoder_timings(), and
never from intel_vrr_transcoder_enable().

The main benefit is that intel_vrr_transcoder_enable() becomes symmetric
to intel_vrr_transcoder_disable().

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20251020185038.4272-16-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
 2025-10-25 00:10:58 +03:00
Ville Syrjälä
b10e7c9255 drm/i915/vrr: Disable VRR TG in intel_vrr_transcoder_disable() only on always use_vrr_tg() platforms 
Currently we always disable the VRR timing generator in
intel_vrr_transcoder_disable(). But doing so on !always_use_vrr_tg()
platforms is redundant since we've alreayd disabled the VRR timing
generator earlier in intel_vrr_disable(). Do the disable in
intel_vrr_transcoder_disable() only on always_on_vrr_tg() platforms.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20251020185038.4272-15-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
 2025-10-25 00:10:58 +03:00
Ville Syrjälä
eaa81a600a drm/i915/vrr: Extract intel_vrr_tg_enable() 
Extract the VRR timing generator enable into intel_vrr_tg_enable(),
as a counterpart to intel_vrr_tg_disable().

Note that the CMRR part is probably broken, but so are other
things in the CMRR implementation, and thus it is currently
disabled.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20251020185038.4272-14-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
 2025-10-25 00:10:58 +03:00
Ville Syrjälä
c4b44d1820 drm/i915/vrr: Extract intel_vrr_tg_disable() 
Now that we always disable the VRR timing generator the same way
we can extract the duplicated code into a helper.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20251020185038.4272-13-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
 2025-10-25 00:10:58 +03:00
Ville Syrjälä
60de042266 drm/i915/vrr: Use trans_vrr_ctl() in intel_vrr_transcoder_disable() 
Currently intel_vrr_disable() writes TRANS_VRR_CTL() with
trans_vrr_ctl(), whereas intel_vrr_transcoder_disable() always
writes just a plain 0. Write trans_vrr_ctl() in both places to
unify the code, allowing for more shared code in the future.

Since the VRR timing generator will be disabled by the
TRANS_VRR_CTL write it doesn't really matter what we write to
the register (other than VRR_CTL_VRR_ENABLE that is).

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20251020185038.4272-12-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
 2025-10-25 00:10:58 +03:00
Ville Syrjälä
4353128252 drm/i915/vrr: Move EMP_AS_SDP_TL write into intel_vrr_set_transcoder_timings() 
EMP_AS_SDL_TL replaces the TRANS_VRR_VSYNC for the purposes of
setting the AS SDP transmission line. Move the EMP_AS_SDL_TL into
intel_vrr_set_transcoder_timings() since that's where we write
TRANS_VRR_VSYNC as well.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20251020185038.4272-11-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
 2025-10-25 00:10:58 +03:00
Ville Syrjälä
587db4b310 drm/i915/vrr: Avoid redundant TRANS_PUSH write in intel_vrr_enable() 
We keep TRANS_PUSH_EN always set for always_use_vrr_tg() platfforms,
so there is no need to write it again in  intel_vrr_enable().

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20251020185038.4272-10-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
 2025-10-25 00:10:58 +03:00
Ville Syrjälä
909cc33702 drm/i915/vrr: Extract intel_vrr_set_vrr_timings() 
Extract intel_vrr_set_vrr_timings() as the counterpart to
intel_vrr_set_fixed_rr_timings().

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20251020185038.4272-9-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
 2025-10-25 00:10:58 +03:00
Ville Syrjälä
291119eb18 drm/i915/vrr: Move compute_fixed_rr_timings() 
Relocate intel_vrr_compute_fixed_rr_timings() next to its
VRR and CMRR counterparts.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20251020185038.4272-8-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
 2025-10-25 00:10:58 +03:00
Ville Syrjälä
8a553374db drm/i195/vrr: Move crtc_state->vrr.{vmin,vmax} update into intel_vrr_compute_vrr_timings() 
The way intel_vrr_compute_*_timings() works is rather confusing.
First intel_vrr_compute_config() assigns the computed vmin/vmax
into crtc_state->vrr.{vmin,vmax}, and then either
intel_vrr_compute_vrr_timings() leaves them untouched or
intel_vrr_compute_{cmrr,fixed_rr}_timings() overwrite them with
something else.

Clean this up by moving all crtc_state->vrr.{vmin,vmax} assignments
into intel_vrr_compute_*_timings().

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20251020185038.4272-7-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
 2025-10-25 00:10:58 +03:00
Ville Syrjälä
4082842e39 drm/i915/vrr: Reorganize intel_vrr_compute_cmrr_timings() a bit 
Move the cmrr.enable assignment next to the mode_flags assignment
to keep things in a bit more logical order in
intel_vrr_compute_cmrr_timings().

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20251020185038.4272-6-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
 2025-10-25 00:10:58 +03:00
Ville Syrjälä
a5fac6761c drm/i915/vrr: Compute fixed refresh rate timings the same way as CMRR timings 
Unify the VRR timing computation stuff a bit having both the
fixed refresh rate and CMRR cases assign the crtc_state->vrr
stuff in exactly the same way.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20251020185038.4272-5-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
 2025-10-25 00:10:53 +03:00
Ville Syrjälä
ec5fd6e754 drm/i915: Remove the "vblank delay" state dump 
The "vblank delay" we are including in the crtc state dump is
meaningful only when running with fixed refresh rate timings.
With VRR timings one has to look at the VRR state to figure out
the same thing.

Since we already dump the position of the delayed vblank for
both fixed refresh rate and VRR timings, this "vblank delay"
thing seems pretty much pointless now. Get rid of it.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20251020185038.4272-4-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
 2025-10-24 23:54:48 +03:00
Ville Syrjälä
d239335e3c drm/i915/lrr: Include SCL in lrr_params_changed() 
If SCL is changing we need to take the LRR codepath to update
it during a fastset. Account for that in lrr_params_changed().

The current code will only notice the SCL change if the position
of the delayed vblank also changes. But that might not happen
when using the VRR timing generator because the delayed vblank
is then defined by the guardband instead of the SCL.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20251020185038.4272-3-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
 2025-10-24 23:54:40 +03:00
Ville Syrjälä
aa88371928 drm/i915/vrr: Fix intel_vrr_always_use_vrr_tg()==true on TGL 
On TGL the hardware always needs TRANS_VBLANK.VBLANK_START
to be programemd with VACTIVE+SCL. Make it so.

The current way of programming it with crtc_vblank_start only
works for the legacy timing generator, as there the delayed
vblank does happen exactly at VACTIVE+SCL.

But if one tries to change intel_vrr_always_use_vrr_tg() to
always use the VRR timing generator on TGL, crtc_vblank_start
will point to the VRR timing generator's delayed vblank,
which may not match VACTIVE+SCL.

Fortunately the state checker caught the issue right away
when I tried intel_vrr_always_use_vrr_tg()==true on TGL.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20251020185038.4272-2-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
 2025-10-24 23:53:52 +03:00
Ruben Wauters
b9e5e9d2c1 drm/gud: rearrange gud_probe() to prepare for function splitting 
gud_probe() is currently very large and does many things, including
pipeline setup and feature detection, as well as having USB functions.

This patch re-orders the code in gud_probe() to make it more organised
and easier to split apart in the future.

Signed-off-by: Ruben Wauters <rubenru09@aol.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://lore.kernel.org/r/20251020140147.5017-1-rubenru09@aol.com/
 2025-10-24 19:36:45 +01:00
Thomas Zimmermann
5efbe8ff98 Merge drm/drm-next into drm-misc-next 
Backmerging to get fixes and features of v6.18-rc2.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
 2025-10-24 14:45:08 +02:00
Simona Vetter
18b1ce0b29 Merge tag 'drm-xe-fixes-2025-10-23' of https://gitlab.freedesktop.org/drm/xe/kernel into drm-fixes 
UAPI Changes:
 - Make madvise autoreset an explicit behavior requested by userspace
   (Thomas Hellström)

Driver Changes:
 - Drop XE_VMA flag conversion and ensure GPUVA flags are passed around
   (homas Hellström)
 - Fix missing wq allocation error checking (Matthew Brost)

Signed-off-by: Simona Vetter <simona.vetter@ffwll.ch>
From: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://lore.kernel.org/r/4p2glnvgifc6osjlvzv23xhsyqhw4diqlfxz54lmg7robv44bi@nwd37zpqfa2l
 2025-10-24 13:39:21 +02:00
Simona Vetter
adb0971a1a Merge tag 'drm-intel-fixes-2025-10-23' of https://gitlab.freedesktop.org/drm/i915/kernel into drm-fixes 
- Fix panic structure allocation memory leak (Jani)

Signed-off-by: Simona Vetter <simona.vetter@ffwll.ch>
From: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://lore.kernel.org/r/aPojgsvNYOU0tN4U@intel.com
 2025-10-24 13:36:48 +02:00
Simona Vetter
0cdf7f6fa6 Merge tag 'drm-misc-fixes-2025-10-23' of https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes 
Short summary of fixes pull:

panic:
- Fix several issues in size calculations

panthor:
- Fix kernel panic on partial unmap of GPU VA region

rockchip:
- hdmi: Fix HDP setup

Signed-off-by: Simona Vetter <simona.vetter@ffwll.ch>
From: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://lore.kernel.org/r/20251023083449.GA13190@linux-2.fritz.box
 2025-10-24 13:35:26 +02:00
Simona Vetter
098456f314 Merge tag 'drm-misc-next-2025-10-21' of https://gitlab.freedesktop.org/drm/misc/kernel into drm-next 
drm-misc-next for v6.19:

UAPI Changes:

amdxdna:
- Support reading last hardware error

Cross-subsystem Changes:

dma-buf:
- heaps: Create heap per CMA reserved location; Improve user-space documentation

Core Changes:

atomic:
- Clean up and improve state-handling interfaces, update drivers

bridge:
- Improve ref counting

buddy:
- Optimize block management

Driver Changes:

amdxdna:
- Fix runtime power management
- Support firmware debug output

ast:
- Set quirks for each chip model

atmel-hlcdc:
- Set LCDC_ATTRE register in plane disable
- Set correct values for plane scaler

bochs:
- Use vblank timer

bridge:
- synopsis: Support CEC; Init timer with correct frequency

cirrus-qemu:
- Use vblank timer

imx:
- Clean up

ivu:
- Update JSM API to 3.33.0
- Reset engine on more job errors
- Return correct error codes for jobs

komeda:
- Use drm_ logging functions

panel:
- edp: Support AUO B116XAN02.0

panfrost:
- Embed struct drm_driver in Panfrost device
- Improve error handling
- Clean up job handling

panthor:
- Support custom ASN_HASH for mt8196

renesas:
- rz-du: Fix dependencies

rockchip:
- dsi: Add support for RK3368
- Fix LUT size for RK3386

sitronix:
- Fix output position when clearing screens

qaic:
- Support dma-buf exports
- Support new firmware's READ_DATA implementation
- Replace kcalloc with memdup
- Replace snprintf() with sysfs_emit()
- Avoid overflows in arithmetics
- Clean up
- Fixes

qxl:
- Use vblank timer

rockchip:
- Clean up mode-setting code

vgem:
- Fix fence timer deadlock

virtgpu:
- Use vblank timer

Signed-off-by: Simona Vetter <simona.vetter@ffwll.ch>

From: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://lore.kernel.org/r/20251021111837.GA40643@linux.fritz.box
 2025-10-24 13:25:20 +02:00
Jani Nikula
0790925dad drm/{i915,xe}/fbdev: add intel_fbdev_fb_pitch_align() 
For reasons still unknown, xe appears to require a stride alignment of
XE_PAGE_SIZE, and using 64 leads to sporadic failures. Go back to having
separate stride alignment for i915 and xe, until the issue is root
caused.

v2: Add FIXME comment, reference issue with Link (Ville)

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Jouni Högander <jouni.hogander@intel.com>
Cc: Maarten Lankhorst <maarten@lankhorst.se>
Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/6220
Fixes: 4a36b339a1 ("drm/xe/fbdev: use the same 64-byte stride alignment as i915")
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/ae51d1e224048bdc87bf7a56d8f5ebd0fbb6a383.1756931441.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://lore.kernel.org/r/20251022161054.708388-1-jani.nikula@intel.com
 2025-10-24 11:31:43 +03:00
Thomas Zimmermann
57fe8285dc drm/client: Do not free client memory by default 
Make no assumption on the allocation of the client's memory. For
example, amdgpu stores a client within another data structures,
where it cannot be freed by itself.

The correct place to free the client's memory is the client's free
callback. All existing clients implement this.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://lore.kernel.org/r/20251009132006.45834-5-tzimmermann@suse.de
 2025-10-24 08:45:37 +02:00
Thomas Zimmermann
52a0233916 drm/log: Add free callback 
Free the client memory in the client free callback. Also move the
debugging output into the free callback: drm_client_release() puts
the reference on the DRM device, so pointers to the device should
be considered dangling afterwards.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>>
Link: https://lore.kernel.org/r/20251009132006.45834-4-tzimmermann@suse.de
 2025-10-24 08:45:37 +02:00
Thomas Zimmermann
33ba21e9e1 drm/log: Do not hold lock across drm_client_release() 
When calling drm_client_release(), the client is already quiescent.
Internal locks should therefore be dropped before the caller releases
the client.

In the case of the DRM log, concurrency originates from the console or
from client events. The console has been unregistered in the previous
line. The caller of the unregister callback, drm_log_client_unregister(),
holds clientlist_mutex from struct drm_device to protect against concurrent
client events. It is therefore safe to release the client without holding
locks.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>>
Link: https://lore.kernel.org/r/20251009132006.45834-3-tzimmermann@suse.de
 2025-10-24 08:45:37 +02:00