| Age | Commit message (Collapse) | Author |
|---|
|
https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes
Short summary of fixes pull:
bridge:
- ssd2825: Fix panel enable sequence
- sii902x: validate I2S data lane values
display:
- hdmi: Fixes to SCDC
gud:
- Avoid divide error in gud_stats_debugfs
meson:
- load ENCL gamma table while ENCL is disabled
nouveau:
- disp: Set atomic functions in struct drm_mode_config_funcs
- gsp: Handle only IRQs routed to host
panfrost:
- Fixes to perfcnt
sched:
- Ensure stopped entity cannot be re-added to the run-queue
vc4:
- Fix firmware reference leak
- Hold runtime PM reference while allocating the binner BO
- Rebuild V3D interrupt mask on every power transition
- Re-enable the V3D interrupt after a GPU reset
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patch.msgid.link/20261113074438.GA14592@linux.fritz.box
|
|
https://gitlab.freedesktop.org/drm/xe/kernel into drm-fixes
Driver Changes:
- select configfs (Arnd)
- Sync Wa_16023105232 in xe_was to match OOB rule (Gustavo)
- Program LMTT directory pointer from each GT init path (Satya)
- Demote uncorrectable local error log on CRI (Varun)
- Apply tile workarounds after PCODE init (Daniel)
- VRAM offlining fixes (Tejas)
- ras: Fix sysctrl and drm-ras discrepancy (Roper)
- pat: Return error from xe_pat_init_early() on unknown (Roper)
- Prevent VF memory IRQ from accessing a torn-down engine (Piotr)
- guc: Protect timeout handling from device unplug (Satya)
- gt: Disable GT reset worker before engine teardown (Satya)
- Various hwmon fixes (Karthik)
- tuning: Restrict Anyhit NULL-query tuning to render engines (Nitin)
- gsc: Fix NVL-S GSC compatibility number (Daniele)
- Don't abort the shrinker walk on -EBUSY (Thomas)
- Mark xe_vma_ops_alloc() noinline for error injection (Shuicheng)
- lrc: Restore CTX_CS_INDIRECT_CTX_OFFSET programming for pre-Xe2 (Helen)
- Fix build with DRM_XE=y and CONFIGFS_FS=m (Rodrigo)
- madvise: use already clamped pat_index (Auld)
- Various wedging fixes (Raag)
- Rebind BOs evicted before the first LR queue (Arvind)
- Toggle the D3Cold enable flag at runtime resume (Vinay)
- Access GT MMIO after pcode init (Vinay)
- xe_late_bind_fw: Fix firmware leak on missing manifest entry (Badal)
- svm: Preserve default PAT index when resetting VMA attributes (Arvind)
- Unwrap sync fences before adding them as job dependencies (Junjia)
- Schedule disable G2H fixes (Jagmeet)
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Matthew Brost <matthew.brost@intel.com>
Link: https://patch.msgid.link/avZ4bHmL2NTc4W8a@gsse-cloud1.jf.intel.com
|
|
https://gitlab.freedesktop.org/drm/amdgpu/kernel into drm-fixes
amd-drm-fixes-7.4-2026-11-12:
amdgpu:
- DCN 6 DML2 fix
- VCE fixes
- GC 11.0.2 fix
- SMU 15 fix
- Error handling fixes
- Partition fix
- IMU firmware clean up fix
- TLB fence handling fix
amdkfd:
- SVM fixes
- CRIU fixes
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Alex Deucher <alexander.deucher@amd.com>
Link: https://patch.msgid.link/20261112163539.1265175-1-alexander.deucher@amd.com
|
|
vc4_reset() masks the IRQ line through vc4_irq_disable(), which calls
disable_irq(), but nothing in the reset path calls enable_irq(). The line
stays disabled after the first GPU hang, so later jobs only retire through
further hangcheck resets.
Commit 6abc8e4dcfbc ("drm/vc4: Disable the V3D interrupt across runtime
suspend") was written against drm-misc-fixes, where the GPU was still
reset with a runtime suspend/resume cycle and the resume callback
re-enabled the line. Commit b4448823f151 ("drm/vc4: Use the reset
controller to recover from a GPU hang") removed that cycle, so once both
landed, enable_irq() was no longer reached.
Move enable_irq() into vc4_irq_enable(), which both runtime resume and
vc4_irq_reset() call, so every path that disables V3D interrupts also
re-enables the IRQ line.
Fixes: b4448823f151 ("drm/vc4: Use the reset controller to recover from a GPU hang")
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Link: https://patch.msgid.link/20261111-vc4-irq-cleanup-v2-3-aa757bb742f2@igalia.com
Signed-off-by: Maíra Canal <mcanal@igalia.com>
|
|
The out-of-memory interrupt is armed once, by bin_bo_alloc(), when the
binner BO is allocated. vc4_irq_disable() masks it on the way down,
vc4_irq_enable() brings back only the render bits, and bin_bo_alloc() does
not run again for a binner BO that is still referenced. An overflow after
an autosuspend therefore raises nothing and the binner stalls, until the
hangcheck resets the GPU and arms the interrupt again.
Therefore, derive the out-of-memory bit in vc4_irq_enable() from whether a
binner BO exists, which is the condition bin_bo_alloc() was standing in
for.
While here, clear the complement of the wanted mask while enabling.
V3D_INTENA and V3D_INTDIS are set/clear registers and the driver only ever
set bits, so a source left enabled will stay enabled and can reach
vc4_irq(), which returns IRQ_NONE for anything outside the three bits it
handles.
Cc: stable@vger.kernel.org
Fixes: 35c8b4b2c0fe ("drm/vc4: Allocate binner bo when starting to use the V3D")
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Link: https://patch.msgid.link/20261111-vc4-irq-cleanup-v2-2-aa757bb742f2@igalia.com
Signed-off-by: Maíra Canal <mcanal@igalia.com>
|
|
bin_bo_alloc() arms the out-of-memory interrupt once it has allocated the
binner BO, and accessing a V3D register requires the block to be powered.
vc4_submit_cl_ioctl() already holds a runtime PM reference by the time it
reaches vc4_get_bcl(), but vc4_create_bo_ioctl() reaches vc4_grab_bin_bo()
without one, so the write can land on a suspended device.
Take the reference in vc4_v3d_bin_bo_get(), which covers both callers, and
take it before bin_bo_lock so that runtime PM is never waited for with the
mutex held.
Cc: stable@vger.kernel.org
Fixes: 35c8b4b2c0fe ("drm/vc4: Allocate binner bo when starting to use the V3D")
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Link: https://patch.msgid.link/20261111-vc4-irq-cleanup-v2-1-aa757bb742f2@igalia.com
Signed-off-by: Maíra Canal <mcanal@igalia.com>
|
|
The original addition of configfs to xe missed a compile-time dependency,
which leads to a link failure when configfs is enabled as a loadable module:
ld.lld-21: error: undefined symbol: xe_configfs_get_survivability_mode
>>> referenced by xe_survivability_mode.c:224
>>> drivers/gpu/drm/xe/xe_survivability_mode.o:(xe_survivability_mode_is_requested) in archive vmlinux.a
A recent workaround added a 'IS_REACHABLE()' check around the calls into
configfs, which makes it link in this configuration, but this is generally
a bad idea because it makes the actual behavior inconsistent and confusing
to users that expect configfs to work if both xe and configfs are enabled.
Use 'select CONFIGFS_FS' instead, like every other configfs user does,
and remove the unnecessary stub functions. There is little practical
difference here as anyone using XE graphics is likely to have a complex
configuration that already selects configfs anyway, and the link error
or the IS_REACHABLE() would only manifest during randconfig testing.
Fixes: da475c094342 ("drm/xe: Fix build with DRM_XE=y and CONFIGFS_FS=m")
Fixes: 16280ded45fb ("drm/xe: Add configfs to enable survivability mode")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://patch.msgid.link/20261026102603.2045493-1-arnd@kernel.org
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
(cherry picked from commit be73339dd9d70623b7dbc9c4e3b966824b771069)
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
|
|
Wa_16023105232 was extended in xe_wa_oob.rules to match extra IP
releases while the respective entry in xe_was[] was overlooked.
Update the latter to be in sync with the former.
Also add comments in the code so that we don't forget to update both
places if new IP versions are added.
Fixes: c96e0df4e9f5 ("drm/xe/xe3: Add support for media IP version 30.02")
Fixes: 4fde66699f1c ("drm/xe/xe3: Add support for graphics IP versions 30.04 & 30.05")
Cc: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Shekhar Chauhan <shekhar.chauhan@intel.com>
Reviewed-by: Matt Atwood <matthew.s.atwood@intel.com>
Link: https://patch.msgid.link/20261105-wa_16031259911-v3-2-da6ec790aa29@intel.com
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
(cherry picked from commit 0cfb54f8f4d69efc847641738d25065049160aca)
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
|
|
The LMTT directory pointer is configured on every GT of the tile only
from the primary GT's init/reset flow. On new platforms, both primary and
media GTs have their own forcewake. Primary GT's init holds only its own
forcewake, so the media GT write can be lost.
Program the LMTT directory pointer from each GT's own init and restart
path, while that GT's forcewake is held.
Also use MCR registers for primary GT and unicast registers for media GT.
Fixes: ad69d62588cd ("drm/xe/pf: Program LMTT directory pointer on all GTs within a tile")
Signed-off-by: Satyanarayana K V P <satyanarayana.k.v.p@intel.com>
Cc: Piotr Piórkowski <piotr.piorkowski@intel.com>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Cc: Stuart Summers <stuart.summers@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patch.msgid.link/20261105114923.880265-4-satyanarayana.k.v.p@intel.com
(cherry picked from commit a8653bee6a0404e9962e80894eae0afab355cbd3)
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
|
|
The UNCORRECTABLE_LOCAL_ERROR notification sent by the GuC indicates a
local, queue-level context termination rather than a global device or
driver failure. On CRI, due to a hardware limitation, the platform cannot
distinguish GT translation faults from true RAS conditions, meaning
standard workloads routinely trigger this error.
Printing this at ERROR level is too noisy and causes false-positive
dmesg-warn failures in CI. Demote the log level to debug for CRI.
v5:
- Correct commmit message and comment (Tejas)
v4:
- Change to _dbg instead of _info. (Matt)
v3:
- Limit the demotion to CRI and add comment explaining the HW limitation
(Rodrigo)
v2:
- Also ratelimit the GUC_ID_UNKNOWN to match the CAT error handler.
(Himal)
Fixes: 4e57574fa3a3 ("drm/xe/guc: Handle GuC local uncorrectable error notifications")
Reviewed-by: Tejas Upadhyay <tejas.upadhyay@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Varun Gupta <varun.gupta@intel.com>
Link: https://patch.msgid.link/20261106034804.2005214-2-varun.gupta@intel.com
Signed-off-by: Tejas Upadhyay <tejas.upadhyay@intel.com>
(cherry picked from commit e305536554790e06876dd4e4f854c97d1353aa79)
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
|
|
Tile workarounds program SoC registers through MMIO. Wait for PCODE
initialization to complete before applying them during system resume,
since MMIO access may be blocked until SoC initialization completes.
Also apply tile workarounds after PCODE initialization on D3cold runtime
resume, so their register settings are restored after power loss. Keep
both paths ordered before early GT resume.
Fixes: 0d0534750f9d ("drm/xe/wa: Apply tile workarounds at probe/resume")
Signed-off-by: Daniel Charles <daniel.charles@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patch.msgid.link/20261103021418.654723-2-daniel.charles@intel.com
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
(cherry picked from commit 641ffb2132839242e49a158d2aea579a75fa2e8e)
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
|
|
Messed up rc1, backmerging rc2.
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
|
|
gud_stats_debugfs() computes the compression ratio by dividing the
accumulated uncompressed length by stats_actual_length. That counter is
zero until the first framebuffer flush has completed, so reading the
stats debugfs file on a display which negotiates LZ4 compression raises
a divide error before any frame has been sent. The wrap-around reset in
gud_flush_rect() also clears the counter for a moment, which a
concurrent read can observe.
Copy the counter into a local variable and skip the ratio computation
when it is zero.
Fixes: 40e1a70b4aed ("drm: Add GUD USB Display driver")
Cc: stable@vger.kernel.org
Co-developed-by: Bin Yu <byu@xidian.edu.cn>
Signed-off-by: Bin Yu <byu@xidian.edu.cn>
Co-developed-by: Cheng Wen <wencheng@xidian.edu.cn>
Signed-off-by: Cheng Wen <wencheng@xidian.edu.cn>
Signed-off-by: YuanZhe Liu <25031212351@stu.xidian.edu.cn>
Acked-by: Ruben Wauters <rubenru09@aol.com>
Link: https://patch.msgid.link/20261029073311.14556-1-25031212351@stu.xidian.edu.cn
Signed-off-by: Ruben Wauters <rubenru09@aol.com>
|
|
commit 604826acb3f5 attempted to add these flags but
commit 6c65db809796 reverted it due to it
failing on hw from pre-atomic times.
So use a second set of functions.
original commit msg from Lyude:
"Apparently we never actually filled these in, despite the fact that we do
in fact technically support atomic modesetting.
Since not having these filled in causes us to potentially forget to disable
fbdev and friends during suspend/resume, let's fix it."
Reported-by: Ruben Wauters <rubenru09@aol.com>
Closes: https://gitlab.freedesktop.org/drm/nouveau/-/work_items/517
Fixes: 6c65db809796 ("Revert "drm/nouveau/disp: Set drm_mode_config_funcs.atomic_(check|commit)"")
Cc: stable@vger.kernel.org
Reviewed-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Link: https://patch.msgid.link/20261111-nouveau-atomic-fix-v1-1-118e65d3a2f5@redhat.com
|
|
After each unmap it might be necessary to invalidate the TLB to flush out
VM changes to the HW and make it visible to executing work.
We tracked that as part of the vm->last_update fence, but as pointed out
by David it can be that this is overwritten by PDE updates when we have a
combined unmap/map operation.
In that case userspace doesn't correctly wait for the TLB invalidation to
finish leading to all kind of problems (sq_int, page faults etc...).
v2: fix ref leaking and error handling as pointed out by AI
v3: fix inverted ! pointed out by Benjamin
v4: fix || / && pointed out by Benjamin
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Felix Kuehling <felix.kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 892f46c7ae70969dbe0e0b88b5864df6f5582b98)
Cc: stable@vger.kernel.org
|
|
kfd_criu_restore_svm() allocated the per-range metadata before checking
that the range fits in the user supplied private data buffer, so an out
of range offset cost a pointless kzalloc()/kfree() round trip. Do the
bounds check first and return -EINVAL directly.
v2:
- split the original patch into two, one change per patch (Yifan)
Signed-off-by: Perry Yuan <perry.yuan@amd.com>
Reviewed-by: Yifan Zhang <yifan1.zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 0c3caec1161e458092364cb448e5bd165a26dcdb)
Cc: stable@vger.kernel.org
|
|
The IMU firmware of GFX11 and GFX12 is only released when loading the
microcode fails. Every unload or unbind of such a device leaks it. On
navi31, binding and unbinding the device leaves:
unreferenced object 0xffff88810dd6cd80 (size 32):
comm "modprobe", pid 2891, jiffies 4294943088
backtrace:
_request_firmware+0x207/0xad0
request_firmware+0x3b/0x60
amdgpu_ucode_request+0x150/0x330 [amdgpu]
amdgpu_device_init+0x2d70/0xa650 [amdgpu]
amdgpu_driver_load_kms+0x1e/0x140 [amdgpu]
a struct firmware of 132352 bytes, the size of gc_11_0_0_imu.bin.
Release it in the free_microcode() functions; with that it's gone.
Fixes: 289bcffb9d76 ("drm/amdgpu: support imu for gfx11")
Fixes: 32d163768989 ("drm/amd/amdgpu: imu fw loading support")
Fixes: a0f8297068cf ("drm/amdgpu: add imu support for gc 12_1")
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit ae8aff53de906d98982e3dc3c691a72eb81c844b)
Cc: stable@vger.kernel.org
|
|
NPS mode change request doesn't allow to request the current mode. This
causes an issue where a user stores a request and later wants to cancel
the request by writing the current mode back. The pending request stays
the same as before.
Allow user to change the mode by comparing against the cached request.
Writing the current mode back clears the pending request without asking
for a reload.
Fixes: 012be6f22c01 ("drm/amdgpu: Add sysfs interfaces for NPS mode")
Signed-off-by: Lijo Lazar <lijo.lazar@amd.com>
Reviewed-by: Asad Kamal <asad.kamal@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 595b5879f1bf776a8c2d085253d3bff2d19dfb57)
Cc: stable@vger.kernel.org
|
|
When initializing the immediate entity fails, amdgpu_vm_init_entities()
destroys that entity which was never set up, and when initializing the
delayed entity fails, it returns without destroying the immediate one.
On navi48, with the allocation of the immediate entity's scheduler list
failing through failslab while opening the render node:
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] SMP KASAN NOPTI
KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]
RIP: 0010:do_raw_spin_lock+0x7b/0x280
_raw_spin_lock+0x3c/0x50
drm_sched_rq_remove_entity+0x90/0x2a0 [gpu_sched]
drm_sched_entity_kill+0x86/0x5a0 [gpu_sched]
drm_sched_entity_fini+0x23/0x270 [gpu_sched]
drm_sched_entity_destroy+0x24/0x30 [gpu_sched]
amdgpu_vm_init_entities+0xc7/0x100 [amdgpu]
amdgpu_vm_init+0x5d1/0x1480 [amdgpu]
amdgpu_driver_open_kms+0x2b1/0xd10 [amdgpu]
Only destroy the immediate entity once it exists and the delayed one
failed.
Fixes: 55bf196f60df ("drm/amdgpu: reset VM when an error is detected")
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 2f538f57501a71baeb7116ff7485f9a7025e4fb9)
Cc: stable@vger.kernel.org
|
|
SMU 15.0.0 no longer implements SMU_MSG_SetHardMinGfxClk, or the
SMU_MSG_SetHardMin and SMU_MSG_SetHardMax messages. Sending them
makes the clock request fail.
Program the GFX hard-min clock with SMU_MSG_SetSoftMinGfxclk, which
this SMU firmware still supports.
Fixes: c7fc0f372374 ("drm/amd: Enable SMU 15_0_0 support")
Signed-off-by: Kanala Ramalingeswara Reddy <Kanala.RamalingeswaraReddy@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit a6ae245cea297fae613145d5e4c74145f81f2ee1)
Cc: stable@vger.kernel.org
|
|
criu_checkpoint_bos() asks every device of the process whether a BO is
mapped there, passing its drm_priv, which is NULL for the devices the
process never acquired a VM on. On navi48 with its iGPU, checkpointing a
process which acquired the VM of the dGPU only:
Oops: general protection fault, probably for non-canonical address 0xdffffc000000002f: 0000 [#1] SMP KASAN NOPTI
KASAN: null-ptr-deref in range [0x0000000000000178-0x000000000000017f]
RIP: 0010:amdgpu_amdkfd_bo_mapped_to_dev+0x35/0x160 [amdgpu]
kfd_ioctl_criu+0x30d1/0x4aa0 [amdgpu]
kfd_ioctl+0x767/0xb10 [amdgpu]
Nothing can be mapped on such a device, skip it.
Fixes: f9e292cbba21 ("drm/amdkfd: kfd_bo_mapped_dev support partition")
Reviewed-by: Felix Kuehling <felix.kuehling@amd.com>
Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 794381c358d344d8fcf8b9e6426aa2bac0a7d1f7)
Cc: stable@vger.kernel.org
|
|
In normal kfd queue create, a reference to the cwsr svm range
is acquired so that this buffer is not freed from underneath the
queue. We weren't doing that.
After svm ranges are restored in RESUME phase of CRIU, go through
all the queues and acquire a reference to the cwsr.
Signed-off-by: David Francis <David.Francis@amd.com>
Reviewed-by: Felix Kuehling <felix.kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 5a00bdd267a5d87307f9aaddabf550f2410c9d40)
Cc: stable@vger.kernel.org
|
|
CRIU queue restore doesn't acquire the bo buffers in the same way
normal queue creation does. In normal queue creation, the driver
gets an additional reference on the queue's underlying buffers
that lasts until the queue is destroyed; this prevents the
queue's buffers from being removed from underneath it.
Acquire them, but don't get the svm bo. SVM isn't yet fully
restored by this point in CRIU and so there's no svm range to get.
This will be addressed in the next patch.
v2: Don't use checkpoint ctl_stack_size
v5: Also avoid cwsr in criu failure path
Signed-off-by: David Francis <David.Francis@amd.com>
Reviewed-by: Felix Kuehling <felix.kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 56ca6fb5b148eb045aef34c4e05f1f56864611d5)
Cc: stable@vger.kernel.org
|
|
In create command we get pitch and height for DPB, input surface
pitch and height is in encode command.
Fix the calculation to also consider different luma and chroma pitch.
Acked-by: Leo Liu <leo.liu@amd.com>
Reviewed-by: Ruijing Dong <ruijing.dong@amd.com>
Signed-off-by: David Rosca <david.rosca@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 24c0be8ac3ef2eaa20f614b540e41382b5e97afc)
Cc: stable@vger.kernel.org
|
|
In svm_migrate_copy_to_vram(), skip VRAM pages with a non-zero refcount
and leave those pages in system memory for this migration.
When an svm_bo is reused, a VRAM page can still be held by an in-flight
CPU fault (do_swap_page -> svm_migrate_to_ram). Migrating to VRAM then
re-initializes the page via zone_device_page_init(), resetting its
refcount. The fault's late put_page() frees the page mid-migration, so
migrate_vma_finalize() never restores that PTE. It is left pointing at a
freed system page and hmm_range_fault() hits BUG_ON in
pfn_swap_entry_to_page() (swapops.h).
Signed-off-by: Apurv Mishra <Apurv.Mishra@amd.com>
Reviewed-by: Philip Yang <Philip.Yang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 1f19aa7acacbce35584dd8f75a30880096fda6a4)
Cc: stable@vger.kernel.org
|
|
GC 11.0.2 (Navi33) never got the GFX MGCG, FGCG and PERF_CLK clock
gating flags. GC 11.0.0, 11.0.1 and 11.0.4 have all three, GC 11.0.3
has MGCG. The gfx_v11_0 code behind these flags is shared by all
GC 11 parts. Enable them for GC 11.0.2, same as for GC 11.0.0.
Without the flags the driver does not clear the override bits in
RLC_CGTT_MGCG_OVERRIDE (0x000605e7 under load), so this gating stays
off. On RX 7600S the GFX clock is limited by the GFX TDC limit
(68 A), in Linux and in Windows. With the gating off each MHz costs
more GFX current, so PMFW stops at a lower clock than in Windows.
vkpeak fp32-scalar for 300 s, median after the first 60 s, GFX
current is about 68 A (TDC limit) in all cases:
gfxclk VDDGFX GFLOPS
current flags 2030 MHz 800 mV 8915
+ MGCG 2261 MHz 873 mV 9921
+ MGCG, FGCG, PERF_CLK 2314 MHz 894 mV 10104
Windows 11, AMD driver 910 mV 10157-10186
GFLOPS per MHz is the same, only the current per clock goes down.
Windows shows other clock sensors, so there I compare GFLOPS only.
With all three flags vkpeak is within 1% of Windows. MGCG gives most
of the gain, FGCG and PERF_CLK add about 2% more.
Tested on one laptop, ASUS TUF A16 FA617NS (RX 7600S, PMFW 82.97.0),
Fedora kernel 7.2.11, Mesa 26.2.5, with the same flags set by a local
debug patch. One 300 s vkpeak run for each setting and some gaming,
no amdgpu errors in dmesg. Suspend/resume and long runs are not
tested yet.
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/6082
Signed-off-by: Andrei Krautsou <an9949an@gmail.com>
Reviewed-by: Kenneth Feng <kenneth.feng@amd.com>
Signed-off-by: Andrei Krautsou <an9949an@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 85e5015b7879c04f7b9aabc865cdf7bcdf3d7470)
Cc: stable@vger.kernel.org
|
|
It turns out that the VCE_STATUS register bits that we
used to check whether VCE1 is idle are actually not useful:
VCE_STATUS.JOB_BUSY doesn't exist until VCE3
VCE_STATUS.UENC_BUSY seems to be stuck high on Cape Verde
Instead, do the following:
Check that the read and write pointer matches for each ring.
Check VCE_STATUS.VCPU_REPORT bits to check busy status.
Finally, also check SRBM_STATUS2.VCE_BUSY just in case,
although this one seems bogus on VCE1.
Fixes: d4a640d4b9f3 ("drm/amdgpu/vce1: Implement VCE1 IP block (v2)")
Acked-by: David Rosca <david.rosca@amd.com>
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Signed-off-by: David Rosca <david.rosca@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 0db6125a171f81422736850e3a7fefdf23380073)
Cc: stable@vger.kernel.org
|
|
[Why&How]
dchub_v2_get_sop_total_available_bandwidth_KBps() and
dchub_v2_is_qos_bandwidth_supported_by_sop() divide 64-bit integers
by 100. On 32-bit builds this emits a call to __udivdi3, which the
kernel does not link.
Use double-cast division instead.
Fixes: 7f7d7ea1fa51 ("drm/amd/display: Add new sources for DCN6")
Cc: Linlin Yang <yanglinlin@kylinos.cn>
Cc: Mario Limonciello <mario.limonciello@amd.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Dillon Varone <dillon.varone@amd.com>
Signed-off-by: Ivan Lipski <ivan.lipski@amd.com>
Reviewed-by: Alex Hung <alex.hung@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 83e7c8cb33363f2a2f893758c630f9a805ac4573)
Cc: stable@vger.kernel.org
|
|
Currently, in the case of a single bridge and a single panel, the DRM
framework calls panel prepare() > bridge pre_enable() > bridge enable() >
panel enable(). While this is fine for most cases, the SSD2825 requires
the last two steps to be swapped. There is no meaningful way to achieve
this using standard bridge chain configuration, so the bridge previously
called panel_enable() directly at the end of its pre_enable() hook to
gain fine-grained control over the sequence.
Commit 554d36acf5e0 ("drm/bridge: ssd2825: don't create a panel_bridge")
removed this call, resulting in a regression where display output is
missing because the panel enable function is now called after the bridge
completes its configuration.
Since panels are now automatically wrapped into the bridge framework,
invoke the next bridge's atomic enable directly, similar to how panel
enabling was handled previously.
This restores panel support on the LG Optimus 4X HD (P880) and
Optimus Vu (P895).
Fixes: 554d36acf5e0 ("drm/bridge: ssd2825: don't create a panel_bridge")
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Link: https://patch.msgid.link/20261025133636.253505-1-clamor95@gmail.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
|
|
The sil,i2s-data-lanes property reader bounds the number of entries, but
does not bound each entry's value. Those values index the four-entry
i2s_lane_id table when the audio FIFO sequence is built.
Reject unsupported lane values before indexing that table. Report the
property name and invalid value with dev_err_probe() so the diagnostic
identifies the faulty configuration.
The issue was found by our static-analysis tool.
Fixes: ff5781634c41 ("drm/bridge: sii902x: Implement HDMI audio support")
Assisted-by: gpt 5
Signed-off-by: Pengpeng Hou <hppiscas@163.com>
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Link: https://patch.msgid.link/20260920034833.18874-1-hppiscas@163.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
|
|
An ORIGIN_FLIP flush can clear the last busy frontbuffer bits without
running _psr_flush_handle(), leaving the CFF state flag set.
Clear CFF state when no frontbuffer bits remain busy, and queue PSR
work only when inactive and not paused.
Fixes: 805f04d42a6b ("drm/i915/display/psr: Use continuos full frame to handle frontbuffer invalidations")
Cc: <stable@vger.kernel.org> # v5.19+
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Link: https://patch.msgid.link/20261102100051.272137-4-jouni.hogander@intel.com
(cherry picked from commit 233e3453eb705c0434f6f8467f211f0250c5832b)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
|
|
An ORIGIN_FLIP flush can clear the last busy frontbuffer bits without
queuing the work that re-arms PSR.
Queue the re-arm work after each flush when PSR is inactive and no
frontbuffers are busy.
Move also pipe_frontbuffer_bits ==0 check to done right after pipe
frontbuffer bits are figured out. Anyways nothing is currently done after
in intel_psr_flush if the bits are 0.
v2: Do not re-activate PSR on other pipe frontbuffer bits.
Fixes: ef39826c12b4 ("drm/i915/display: Fix glitches when moving cursor with PSR2 selective fetch enabled")
Cc: <stable@vger.kernel.org> # v5.16+
Tested-by: Ambica Pramod <ambica.pramod@intel.com>
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Link: https://patch.msgid.link/20261102100051.272137-3-jouni.hogander@intel.com
(cherry picked from commit 731ed8af13bdead02924b39a8c01d5f60d6a2e68)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
|
|
fbdev invalidates on set_par, blank, pan_display and restore, but never
flushes. On i915, unrelated rendering may clear the bits; Xe has no
ORIGIN_CS invalidation, so PSR and FBC can remain disabled indefinitely.
Flush after these operations; they are already complete.
Fixes: 44e694958b95 ("drm/xe/display: Implement display support")
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: <stable@vger.kernel.org> # v6.8+
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Link: https://patch.msgid.link/20261102100051.272137-5-jouni.hogander@intel.com
(cherry picked from commit ab965cbc781e4f4f8f81e48d01e0a0d78c94d369)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
|
|
Currently we are not doing flush on cursor update if Selective Fetch is not
in use. This does not cause problems in PSR cases as enabling VBI is
triggering PSR exit which triggers sending update to panel. In case of
Panel Replay this does not happen. This causes legacy cursor update not
working if using Panel Replay without Selective Updates.
Dc3co is currently not enabled. Anyways there is no reason to differentiate
calling psr2_dc3co_flush_locked on cursor update depending on selective
fetch being enabled. So remove this dependency.
v2:
- Keep DC3CO handling for cursor updates.
Fixes: 129a4da11707 ("drm/i915/psr: Use TRANS_PUSH to trigger frame change event")
Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Link: https://patch.msgid.link/20261102100051.272137-2-jouni.hogander@intel.com
(cherry picked from commit 043ab39fe2daad32f15fe77cf787a759f3f73512)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
|
|
When entities are torn down in drm_sched_entity_kill() a multi-step
process is undertaken to synchronize with a drm_sched_run_job_work()
consuming jobs from the same entity.
First the entity is marked as stopped and removed from the run-queue,
with both the entity and run-queue lock correctly taken. The process then
waits for the entity idle via the completion after which point it assumes
it is the only accessor to the entity in question.
What can happen however in drm_sched_run_job_work() if there are at least
two outstanding runnable jobs on an entity, is that
drm_sched_entity_pop_job() can re-add it to the run-queue due the
unconditial add to the rbtree via drm_sched_rq_update_fifo_locked().
What is required is that the teardown starts after the run job has
selected the entity and that it gets to it's completion waiting stage
before the run job goes to dequeue a job, and for the run job to be able
to de-queue a job before teardown has consumed too many.
Run job will then see there is another job pending (after the one about
to be de-queued) and it will re-add the entity to the run-queue. Run job
will then signal the completion and entity teardown will proceed
incorrectly thinking it's removal of the entity was final.
End result is a pointer to an entity about to be freed dangling forever in
the rbtree.
drm_sched_run_job_work() drm_sched_entity_kill()
drm_sched_select_entity
stops and removes entity
wait_for_completion
drm_sched_entity_pop_job
-> re-adds to run-queue due more jobs
complete_all
drm_sched_entity_queue_pop
... fini entity ...
drm_sched_run_job_queue
drm_sched_select_entity - UAF
This race existed ever since the FIFO policy was first added.
Lets mirror the guard from drm_sched_rq_add_entity() in
drm_sched_rq_pop_entity() and close this gap.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
References: https://sashiko.dev/#/patchset/20261020154123.33631-1-tvrtko.ursulin@igalia.com?part=7
Fixes: 08fb97de03aa ("drm/sched: Add FIFO sched policy to run queue")
Cc: Luben Tuikov <luben.tuikov@amd.com>
Cc: Christian König <christian.koenig@amd.com>
Cc: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Danilo Krummrich <dakr@kernel.org>
Cc: Philipp Stanner <phasta@kernel.org>
Cc: David Airlie <airlied@gmail.com>
Cc: Simona Vetter <simona@ffwll.ch>
Cc: stable@vger.kernel.org # v6.2+
Signed-off-by: Philipp Stanner <phasta@kernel.org>
Link: https://patch.msgid.link/20261109160743.17020-1-tvrtko.ursulin@igalia.com
|
|
The GSP's interrupt handler takes every pending interrupt the RISC-V
IRQMASK enables as its own, without looking at IRQDEST, which says
whether an interrupt goes to the host or to the GSP itself. One that
belongs to GSP-RM, pending when the host's handler runs for the message
queue, is reported as unknown, cleared and masked off with IRQMCLR,
taking it away from the firmware:
nouveau 0000:01:00.0: gsp: intr 00040000
NVIDIA's driver reads the interrupts routed to the host as
IRQSTAT & IRQMASK & IRQDEST (kflcnRiscvReadIntrStatus_TU102() and
_GA102()). Do the same, with IRQDEST from NVIDIA's register headers
next to IRQMASK on each falcon.
Seen once in a few boots on an RTX 3070 Ti (GA104, GSP-RM 570.144),
before the login prompt. There IRQMASK reads 0x01049042 and IRQDEST
0x01000040: 0x00040000 is enabled but routed to the GSP.
Fixes: 830531e94712 ("drm/nouveau/gsp/r535: add interrupt handling")
Cc: stable@vger.kernel.org
Signed-off-by: Joe Finzel <joe@sudmix.de>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Link: https://patch.msgid.link/20261023-nouveau-gsp-irqdest-v1-1-5dd6131faa14@sudmix.de
|
|
drm_connector_hdmi_disable_scrambling() only clears the sink SCDC status
when the connector is known to be connected. That is never true when a
source driver disables scrambling at boot to clean up after the
firmware, as vc4 does from vc4_crtc_disable_at_boot(), where
connector->status is still unknown and no EDID has been read.
A sink left scrambling by the firmware thus keeps both Scrambling_Enable
and the 1/40 TMDS bit clock ratio set. If the first modeset picks a
mode below 340 MHz, no disable happens in between, since the CRTC was
never active in atomic state, and drm_connector_hdmi_enable_scrambling()
returns early, leaving the sink trying to descramble an unscrambled
stream.
Instead of blind SCDC writes at boot towards a possibly absent sink,
reset the sink status from drm_connector_hdmi_enable_scrambling() when
no scrambling is required. By then the sink has been probed, and HDMI
2.0 expects a scrambling capable sink to have Scrambling_Enable cleared
below 340 MHz anyway. The reset runs regardless of source scrambler
support, since the firmware may have left the sink scrambling.
Factor the reset out into a helper also used by the disable and error
paths, gated only on drm_scdc_sink_supports_scrambling(), which suffices
because drm_display_info is zeroed until the first EDID read and reset
on disconnect, making the connector->status check redundant. As the
helper now runs on every non-scrambled modeset, read SCDC_TMDS_CONFIG
first and only clear the bits actually set, so the common case costs a
single DDC read.
Fixes: d653818324ed ("drm/display: hdmi: Add HDMI 2.0 scrambling management helpers")
Reviewed-by: Maíra Canal <mcanal@igalia.com>
Link: https://patch.msgid.link/20261104-hdmi-scdc-scramb-fixes-v1-3-16a9bb3d64a6@collabora.com
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
|
|
drm_connector_hdmi_sync_scdc() uses the scrambler_enabled flag to decide
whether the sink-side SCDC status is worth checking on a hotplug/detect
event. That flag tracks the source-side scrambler status, which is not
necessarily in sync with what the committed mode actually requires.
In particular, a source driver may deliberately set scrambler_enabled at
init to force a disable at boot and resync hardware left enabled by the
firmware, as vc4 does. If the pipeline doesn't get disabled afterwards,
e.g. because no display was active at probe time, the flag remains
stale. A subsequent detect (e.g. an HPD event) then finds scrambling
disabled on the sink while the flag claims otherwise, and triggers a
CRTC reset. This results in a one-time spurious flicker on an otherwise
correctly configured non-scrambled mode.
Verify conn_state->hdmi.scrambler_needed instead, as it is computed
during atomic check and reliably describes the requirements of the
active mode.
Fixes: d653818324ed ("drm/display: hdmi: Add HDMI 2.0 scrambling management helpers")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://lore.kernel.org/all/sashiko-outbox-170670@kernel.org/
Reviewed-by: Maíra Canal <mcanal@igalia.com>
Link: https://patch.msgid.link/20261104-hdmi-scdc-scramb-fixes-v1-2-16a9bb3d64a6@collabora.com
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
|
|
The connector pointer is used to initialize the local variables hdmi and
dev before the NULL check takes place, leading to the following Smatch
complaint:
drivers/gpu/drm/display/drm_hdmi_helper.c:663 drm_connector_hdmi_sync_scdc()
warn: variable dereferenced before check 'connector' (see line 657)
Move those initializations after the sanity check to avoid a potential
NULL pointer dereference.
Fixes: d653818324ed ("drm/display: hdmi: Add HDMI 2.0 scrambling management helpers")
Reported-by: Dan Carpenter <error27@gmail.com>
Closes: https://lore.kernel.org/all/arJo7A7L5hud3tyc@stanley.mountain/
Reviewed-by: Maíra Canal <mcanal@igalia.com>
Link: https://patch.msgid.link/20261104-hdmi-scdc-scramb-fixes-v1-1-16a9bb3d64a6@collabora.com
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
|
|
struct panfrost_perfcnt::state should always be updated atomically, both
in the dump ioctl and the reset sequence.
Fixes: 9944dd07f3cf ("drm/panfrost: Fix races between perfcnt and reset sequence")
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Steven Price <steven.price@arm.com>
Link: https://patch.msgid.link/20261104-panfrost-reset-races-fixes-v3-2-09868a88c351@collabora.com
Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com>
|
|
If we don't do that, we end up with invalid timestamps in the block
headers.
We also need to skip the warning on the cycle counter reference being
other than 0 during device reset, because of perfcnt's lingering ref.
Ideally this would be dealt with by splitting the reset sequence into
pre and post stages, so that a hypothetical panfrost_perfcnt_pre_reset()
would release the cycle counter reference. In the absence thereof, we
just make do.
Fixes: 7786fd108777 ("drm/panfrost: Expose performance counters through unstable ioctls")
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Steven Price <steven.price@arm.com>
Link: https://patch.msgid.link/20261104-panfrost-reset-races-fixes-v3-1-09868a88c351@collabora.com
Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com>
|
|
The firmware reference taken via rpi_firmware_get() is leaked when
either of the devm_clk_get() calls for the core or display clocks
fails, as both error paths return without releasing it.
Fix it by moving the firmware lookup below the clock lookups, so that
the reference is taken right before the firmware property is read and
released immediately afterwards. The rpi_firmware_find_node() call
moves with it: the device node reference it returns would otherwise be
leaked by those same error paths.
The candidate was found by our static analysis tooling, and this change
was prepared with assistance from DeepSeek-V4.1-Flash and GPT-6.1-Sol.
Fixes: 2a001ca00ad5 ("drm/vc4: hdmi: Rework hdmi_enable_4kp60 detection code")
Cc: stable@vger.kernel.org
Suggested-by: Maíra Canal <mcanal@igalia.com>
Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
Link: https://patch.msgid.link/20261106092016.2282805-1-vulab@iscas.ac.cn
Signed-off-by: Maíra Canal <mcanal@igalia.com>
|
|
On PTL+ platforms with eDP on TypeC, port B's DDI is connected to a C20
TypeC PHY. Identify PHY B as TypeC and map port B to TC_PORT_1 when eDP
TypeC support is enabled.
Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/9196
CC: stable@vger.kernel.org # 6.14+
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20261029113017.618286-7-imre.deak@intel.com
(cherry picked from commit 20e3d954f70486bf14000fc1a6dac7c34e6e4f07)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
|
|
Use the PHY type to identify TypeC ports in the PLL ID lookup function.
This ensures that port B takes the TypeC path when an upcoming change
sets its PHY type to TypeC on PTL+ platforms with an eDP panel connected
to a TypeC PHY.
Keep the existing port >= PORT_TC1 case for BMG, where PORT_TC1 has a
a TypeC DDI (and so uses the TypeC DDI register addresses, has a C20 PHY
and the corresponding TC port -> PLL ID mapping), but this C20 PHY is
not a TypeC PHY (i.e. it's not controlled by the TypeC Subsystem and so
the driver doesn't need to run the TypeC PHY connect/disconnect,
power-on/power-off sequences for the PHY).
v2: Keep handling the BMG TypeC DDI but non-TypeC PHY cases. (Sashiko)
CC: stable@vger.kernel.org # 6.14+
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20261030114456.651066-1-imre.deak@intel.com
(cherry picked from commit 493091a94dca1d832dc0349d1d7e7b3ad369cee7)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
|
|
Handle the TypeC PHY on port B case while mapping the port to an HPD
pin. This prepares for an upcoming change that will set port B's PHY
type to TypeC on PTL+ platforms with an eDP panel connected to a TypeC
PHY.
Keep the existing port >= PORT_TC1 case and its HPD pin mapping for
DG2, where PORT_TC1 has a non-TypeC PHY.
CC: stable@vger.kernel.org # 6.14+
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20261029113017.618286-5-imre.deak@intel.com
(cherry picked from commit 0f35ced2b44db21527cdb80065e80693fb0ab563)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
|
|
Resetting the PPS state involves acquiring an AUX power domain
reference. On TypeC ports, the AUX power domain depends on the TypeC
mode of the port using the PPS.
An upcoming change will set the port/PHY type to TypeC for eDP ports on
PTL+ platforms with an eDP DDI mapped to a TypeC PHY. Prepare for this by
resetting the PPS state on resume only after initializing the port's
TypeC mode.
CC: stable@vger.kernel.org # 6.14+
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20261029113017.618286-4-imre.deak@intel.com
(cherry picked from commit 43eb42b332fe48ab8649bd5e4e0ef351473d8a4a)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
|
|
On TypeC ports, the AUX power domain reference held for PPS VDD requires
the TypeC mode to remain unchanged. Hold a TypeC link reference for the
lifetime of the PPS VDD power reference.
This prepares for an upcoming change that will use the TypeC port type
for eDP on TypeC ports. Allow the additional PPS link reference when
sanitizing the TypeC mode.
CC: stable@vger.kernel.org # 6.14+
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20261029113017.618286-3-imre.deak@intel.com
(cherry picked from commit 3e2444989824139e342aa9affd10cd920255aabc)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
|
|
An upcoming change will need to acquire a TypeC port link reference
along with an AUX power domain reference when enabling PPS VDD for the
port during an AUX transfer. Acquiring the link reference requires
holding the TypeC port lock.
To allow the PPS VDD code to take this lock itself, acquire the TypeC
port lock in the AUX transfer function only after locking PPS and
enabling VDD.
CC: stable@vger.kernel.org # 6.14+
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20261029113017.618286-2-imre.deak@intel.com
(cherry picked from commit 86fabed8d8cf7db734a9a3f63af5f500cf0ed139)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
|
|
meson_encoder_dsi_atomic_enable() programmed the ENCL gamma LUT right
after meson_venc_mipi_dsi_mode_set(), i.e. while the ENCL timing
generator was already running (ENCL_VIDEO_EN=1). Writing the LUT
during active video stalls the hardware: L_GAMMA_CNTL_PORT
WR_RDY/ADR_RDY deassert and the ENCL line counter (ENCL_INFO_READ)
freezes, so every remaining write times out (~8s total at boot) and
the panel ends up with a corrupted gamma table (wrong colors).
Instrumented boots on the ODROID-GO Ultra (S922X) show:
failing: start: VIDEO_EN=1 INFO 0000001a->002d0000 GAMMA_CNTL=00000030
stall: INFO 002d0000->002d0000 GAMMA_CNTL=00000000
(VID_CLK_CNTL2 / VIID_CLK_CNTL / VIID_CLK_DIV unchanged,
i.e. the ENCL clock is still running)
fixed: start: VIDEO_EN=0 INFO 00000000->00000000 GAMMA_CNTL=00000030
no stall, no timeout
Whether it failed depended only on timing, which is why enabling
lock debugging (LOCKDEP etc.) appeared to "fix" it most of the time.
It happens regardless of the bootloader (mainline or Hardkernel vendor
U-Boot).
The function already writes ENCL_VIDEO_EN=0 right afterwards before
re-enabling the encoder, so simply move meson_encl_load_gamma() after
that write. This matches the order used by the vendor U-Boot's own LCD
driver, which never times out.
Tested on the ODROID-GO Ultra with mainline U-Boot: 5 cold boots +
3 warm reboots, no timeouts, correct colors, LOCKDEP disabled.
Fixes: 42dcf15f901c ("drm/meson: add DSI encoder")
Cc: stable@vger.kernel.org
Tested-by: John Williams <porschemad911@gmail.com>
Signed-off-by: Shigeaki Asai <y-asai.0816@docomonet.jp>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patch.msgid.link/20261004-meson-gamma-v1-1-6347558e2bb3@docomonet.jp
|
|
handle_sched_done() treats any SCHED_DONE with runnable_state 0 as the
completion of a suspend whenever q->guc->suspend_pending is set. That is
not sufficient to tell apart the two producers of a scheduling disable.
When a queue is suspended, __guc_exec_queue_suspend() sets
suspend_pending and queues a SUSPEND message. If a job times out before
that message runs, guc_exec_queue_timedout_job() stops submission, which
traps the message, bans the queue and issues a disable of its own via
disable_scheduling(). When the GuC acknowledges that disable,
suspend_pending is still set, so handle_sched_done() misattributes the
reply to the trapped SUSPEND message.
This signals the suspend fence for a queue that was never suspended,
tripping the exec_queue_suspended() assert in suspend_fence_signal(), and
skips the wake_up_all() the TDR is waiting on, so the TDR stalls for its
full 5s timeout and then triggers an unnecessary GT reset.
The suspend path marks the queue suspended before disabling scheduling,
and a trapped SUSPEND message never does, so exec_queue_suspended()
distinguishes the two cases. Use it to qualify the attribution, the same
way the VF migration replay path already does. The trapped message is not
lost: it completes the suspend once submission restarts at the end of the
TDR.
While here, wake guc->ct.wq after clearing pending_disable rather than
before, so a waiter observes the updated state on its first re-check, and
wake unconditionally since the suspend and destroy paths have waiters too.
v2: Rebase onto drm-xe-next. The suspend_pending check moved under
sched->msg_lock in commit cf4171a20d13 ("drm/xe/guc: Fix race
around q->guc->suspend_pending access"), so the
exec_queue_suspended() qualification is folded into that locked
snapshot rather than reinstating an unlocked check. No functional
change from v1.
Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs")
Signed-off-by: Jagmeet Randhawa <jagmeet.randhawa@intel.com>
Reviewed-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com>
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patch.msgid.link/20261020190705.20127-1-jagmeet.randhawa@intel.com
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
