summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm
AgeCommit message (Collapse)AuthorFilesLines
2025-10-28drm/amdgpu: clear bad page info of ras moduleJinzhou Su1-0/+22
Clear bad page info of ras module. Signed-off-by: Jinzhou Su <jinzhou.su@amd.com> Reviewed-by: Tao Zhou <tao.zhou1@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-28drm/amd/display: pause the workload setting in dmKenneth Feng1-0/+11
v1: Pause the workload setting in dm when doinn idle optimization v2: Rebase patch to latest kernel code base (kernel 6.16) Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Kenneth Feng <kenneth.feng@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Yang Wang <kevinyang.wang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-28drm/radeon: Remove calls to drm_put_dev()Daniel Palmer1-21/+4
Since the allocation of the drivers main structure was changed to devm_drm_dev_alloc() drm_put_dev()'ing to trigger it to be free'd should be done by devres. However, drm_put_dev() is still in the probe error and device remove paths. When the driver fails to probe warnings like the following are shown because devres is trying to drm_put_dev() after the driver already did it. [ 5.642230] radeon 0000:01:05.0: probe with driver radeon failed with error -22 [ 5.649605] ------------[ cut here ]------------ [ 5.649607] refcount_t: underflow; use-after-free. [ 5.649620] WARNING: CPU: 0 PID: 357 at lib/refcount.c:28 refcount_warn_saturate+0xbe/0x110 Fixes: a9ed2f052c5c ("drm/radeon: change drm_dev_alloc to devm_drm_dev_alloc") Signed-off-by: Daniel Palmer <daniel@0x0f.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-28drm/radeon: Do not kfree() devres managed rdevDaniel Palmer1-1/+0
Since the allocation of the drivers main structure was changed to devm_drm_dev_alloc() rdev is managed by devres and we shouldn't be calling kfree() on it. This fixes things exploding if the driver probe fails and devres cleans up the rdev after we already free'd it. Fixes: a9ed2f052c5c ("drm/radeon: change drm_dev_alloc to devm_drm_dev_alloc") Signed-off-by: Daniel Palmer <daniel@0x0f.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-28drm/radeon: Clean up pdev->dev instances in probeDaniel Palmer1-4/+5
Get a struct device pointer from the start and use it. Signed-off-by: Daniel Palmer <daniel@0x0f.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-28drm/amd: Check that VPE has reached DPM0 in idle handlerMario Limonciello1-4/+30
[Why] Newer VPE microcode has functionality that will decrease DPM level only when a workload has run for 2 or more seconds. If VPE is turned off before this DPM decrease and the PMFW doesn't reset it when power gating VPE, the SOC can get stuck with a higher DPM level. This can happen from amdgpu's ring buffer test because it's a short quick workload for VPE and VPE is turned off after 1s. [How] In idle handler besides checking fences are drained check PMFW version to determine if it will reset DPM when power gating VPE. If PMFW will not do this, then check VPE DPM level. If it is not DPM0 reschedule delayed work again until it is. v2: squash in return fix (Alex) Cc: Peyton.Lee@amd.com Reported-by: Sultan Alsawaf <sultan@kerneltoast.com> Reviewed-by: Sultan Alsawaf <sultan@kerneltoast.com> Tested-by: Sultan Alsawaf <sultan@kerneltoast.com> Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4615 Reviewed-by: Lijo Lazar <lijo.lazar@amd.com> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-28drm/sched: avoid killing parent entity on child SIGKILLDavid Rosca1-1/+2
The DRM scheduler tracks who last uses an entity and when that process is killed blocks all further submissions to that entity. The problem is that we didn't track who initially created an entity, so when a process accidently leaked its file descriptor to a child and that child got killed, we killed the parent's entities. Avoid that and instead initialize the entities last user on entity creation. This also allows to drop the extra NULL check. Signed-off-by: David Rosca <david.rosca@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com> Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4568 Reviewed-by: Alex Deucher <alexander.deucher@amd.com> CC: stable@vger.kernel.org Acked-by: Philipp Stanner <phasta@kernel.org> Link: https://lore.kernel.org/r/20251015140128.1470-1-christian.koenig@amd.com Signed-off-by: Philipp Stanner <phasta@kernel.org> Link: https://patch.msgid.link/20251015140128.1470-1-christian.koenig@amd.com
2025-10-28drm/ttm: add pgprot handling for RISC-VIcenowy Zheng1-1/+2
The RISC-V Svpbmt privileged extension provides support for overriding page memory coherency attributes, and, along with vendor extensions like Xtheadmae, supports pgprot_{writecombine,noncached} on RISC-V. Adapt the codepath that maps ttm_write_combined to pgprot_writecombine and ttm_noncached to pgprot_noncached to RISC-V, to allow proper page access attributes. Signed-off-by: Icenowy Zheng <uwu@icenowy.me> Tested-by: Han Gao <rabenda.cn@gmail.com> Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com> Link: https://lore.kernel.org/r/20251020053523.731353-1-uwu@icenowy.me
2025-10-28drm/etnaviv: fix flush sequence logicTomeu Vizoso1-1/+1
The current logic uses the flush sequence from the current address space. This is harmless when deducing the flush requirements for the current submit, as either the incoming address space is the same one as the currently active one or we switch context, in which case the flush is unconditional. However, this sequence is also stored as the current flush sequence of the GPU. If we switch context the stored flush sequence will no longer belong to the currently active address space. This incoherency can then cause missed flushes, resulting in translation errors. Fixes: 27b67278e007 ("drm/etnaviv: rework MMU handling") Signed-off-by: Tomeu Vizoso <tomeu@tomeuvizoso.net> Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com> Link: https://lore.kernel.org/r/20251021093723.3887980-1-l.stach@pengutronix.de
2025-10-27drm/xe/pf: Access VF's register using dedicated MMIO viewMichal Wajdeczko3-28/+41
Instead of creating ad-hoc new register definitions with altered register addresses to mimic the VF's access to these registers, prepare new MMIO instance per required VF, with shifted internal location of the register map. This will allow to use unmodified register definitions in all calls to xe_mmio() functions. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patch.msgid.link/20251024205826.4652-1-michal.wajdeczko@intel.com
2025-10-27drm/xe/xe3: Add WA_14024681466 for Xe3_LPGNitin Gote2-0/+5
Apply WA_14024681466 to Xe3_LPG graphics IP versions from 30.00 to 30.05. v2: (Matthew Roper) - Remove stepping filter as workaround applies to all steppings. - Add an engine class filter so it only applies to the RENDER engine. Signed-off-by: Nitin Gote <nitin.r.gote@intel.com> Link: https://patch.msgid.link/20251027092643.335904-1-nitin.r.gote@intel.com Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2025-10-27drm/xe/pf: Fix VF FLR synchronization between all GTsMichal Wajdeczko1-0/+2
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: 2a8fcf7cc950 ("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-27drm/xe: Fix spelling and typos across Xe driver filesSanjay Yadav32-63/+63
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-27drm/nouveau: Fix race in nouveau_sched_fini()Philipp Stanner1-2/+12
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: 5f03a507b29e ("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-27drm/sched: Fix race in drm_sched_entity_select_rq()Philipp Stanner1-1/+2
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: ac4eb83ab255 ("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-27Merge 6.18-rc3 into driver-core-nextGreg Kroah-Hartman61-287/+468
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-26drm/gem-atomic: Reset plane state to NULL if allocation failedThomas Zimmermann1-2/+0
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-26drm/sysfb: Do not dereference NULL pointer in plane resetThomas Zimmermann1-2/+6
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: b71565022031 ("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-25drm/msm: Ensure vm is created in VM_BIND ioctlRob Clark1-1/+1
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: 2e6a8a1fe2b2 ("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-25drm/msm: Reject MAP_NULL op if no PRRRob Clark3-7/+17
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-25drm/xe/configfs: Drop MAX_GT_TYPE_CHARS constantMatt Roper1-2/+1
Early revisions of commit 7abd69278bb5 ("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-25drm/i915/vrr: Check HAS_VRR() first in intel_vrr_is_capable()Ville Syrjälä1-2/+4
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-25drm/i915/vrr: Update the intel_vrr_extra_vblank_delay() commentVille Syrjälä1-4/+2
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-25drm/i915/vrr: Nuke intel_vrr_vmin_flipline()Ville Syrjälä1-7/+2
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-25drm/i915/vrr: Nuke intel_vrr_vblank_exit_length()Ville Syrjälä1-6/+2
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-25drm/i915/vrr: s/crtc_state/old_crtc_state/ in intel_vrr_transcoder_disable()Ville Syrjälä1-4/+4
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-25drm/i915/vrr: Move HAS_VRR() check into intel_vrr_set_transcoder_timings()Ville Syrjälä2-2/+4
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-25drm/i915/vrr: Remove redundant HAS_VRR() checksVille Syrjälä1-6/+0
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-25drm/i915/vrr: Always write TRANS_VRR_CTL in ↵Ville Syrjälä1-9/+3
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-25drm/i915/vrr: Disable VRR TG in intel_vrr_transcoder_disable() only on ↵Ville Syrjälä1-1/+2
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-25drm/i915/vrr: Extract intel_vrr_tg_enable()Ville Syrjälä1-19/+25
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-25drm/i915/vrr: Extract intel_vrr_tg_disable()Ville Syrjälä1-23/+19
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-25drm/i915/vrr: Use trans_vrr_ctl() in intel_vrr_transcoder_disable()Ville Syrjälä1-1/+2
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-25drm/i915/vrr: Move EMP_AS_SDP_TL write into intel_vrr_set_transcoder_timings()Ville Syrjälä1-23/+12
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-25drm/i915/vrr: Avoid redundant TRANS_PUSH write in intel_vrr_enable()Ville Syrjälä1-3/+3
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-25drm/i915/vrr: Extract intel_vrr_set_vrr_timings()Ville Syrjälä1-4/+12
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-25drm/i915/vrr: Move compute_fixed_rr_timings()Ville Syrjälä1-9/+9
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-25drm/i195/vrr: Move crtc_state->vrr.{vmin,vmax} update into ↵Ville Syrjälä1-7/+7
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-25drm/i915/vrr: Reorganize intel_vrr_compute_cmrr_timings() a bitVille Syrjälä1-1/+2
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-25drm/i915/vrr: Compute fixed refresh rate timings the same way as CMRR timingsVille Syrjälä1-5/+3
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-24drm/i915: Remove the "vblank delay" state dumpVille Syrjälä1-3/+1
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-24drm/i915/lrr: Include SCL in lrr_params_changed()Ville Syrjälä1-5/+8
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-24drm/i915/vrr: Fix intel_vrr_always_use_vrr_tg()==true on TGLVille Syrjälä1-0/+6
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-24drm/gud: rearrange gud_probe() to prepare for function splittingRuben Wauters1-21/+24
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-24Merge drm/drm-next into drm-misc-nextThomas Zimmermann184-2295/+4979
Backmerging to get fixes and features of v6.18-rc2. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
2025-10-24Merge tag 'drm-xe-fixes-2025-10-23' of ↵Simona Vetter5-69/+49
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-24Merge tag 'drm-intel-fixes-2025-10-23' of ↵Simona Vetter1-12/+13
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-24Merge tag 'drm-misc-fixes-2025-10-23' of ↵Simona Vetter3-10/+62
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-24Merge tag 'drm-misc-next-2025-10-21' of ↵Simona Vetter100-781/+1552
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-24drm/{i915,xe}/fbdev: add intel_fbdev_fb_pitch_align()Jani Nikula4-1/+20
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: 4a36b339a14a ("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
generated by cgit v1.2.3 (git 2.39.0) at 2026-06-04 09:35:58 +0300