| Age | Commit message (Collapse) | Author |
|---|
|
allocate_usb4_bandwidth_for_stream() and allocate_usb4_bandwidth() both
use ASSERT(stream->sink) before dereferencing stream->sink->link. ASSERT
is compiled out in production builds, so a NULL stream->sink causes a
NULL pointer dereference.
link_set_dpms_off() already guards two earlier accesses to stream->sink
with explicit NULL checks, confirming that stream->sink can legitimately
be NULL. The subsequent call to deallocate_usb4_bandwidth() had no
equivalent guard.
Replace the ASSERT() calls with proper NULL checks that return false
early, and add a matching stream->sink guard at the call site in
link_set_dpms_off() consistent with the surrounding pattern.
v2: Keep the existing ASSERT() calls for diagnostics (to report
unexpected NULL sink), and add explicit NULL checks that return false
before dereferencing stream->sink. Also add a matching stream->sink
guard at the deallocation call site in link_set_dpms_off(). (Alex)
Fixes: 8fa813b7fd1e ("drm/amd/display: Remove sink usage from DPMS")
Reported-by: Dan Carpenter <error27@gmail.com>
Cc: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Cc: Dominik Kaszewski <dominik.kaszewski@amd.com>
Cc: George Zhang <george.zhang@amd.com>
Cc: Aurabindo Pillai <aurabindo.pillai@amd.com>
Cc: Roman Li <Roman.Li@amd.com>
Cc: Ivan Lipski <ivan.lipski@amd.com>
Cc: Dan Wheeler <daniel.wheeler@amd.com>
Cc: Alex Hung <alex.hung@amd.com>
Cc: Tom Chung <chiahsuan.chung@amd.com>
Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com>
Tested-by: Dan Wheeler <daniel.wheeler@amd.com>
Reviewed-by: Roman Li <roman.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Under unified MES both pipes of each XCC run MES firmware, each with its
own scheduler context, and the firmware attaches the dbgext log buffer
only to the pipe that received SETUP_MES_DBGEXT. With a single region
per XCC only one pipe's messages were collected.
Give every (xcc, pipe) its own region in the log buffer, pass the target
pipe in the setup request, and arm, detach and drain every region. Tag
output with the source XCC and pipe ("0"-sched/"1"-kiq) when more than one
region is logged; single-region output is unchanged.
Signed-off-by: Yongqiang Sun <Yongqiang.Sun@amd.com>
Reviewed-by: Shaoyun Liu <Shaoyun.Liu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Set vm_manager.spm_vmid to the top GFXHUB VMID so the SPM reservation
path hands out a fixed, isolated VMID on gfx9 instead of borrowing one
from the graphics pool.
Signed-off-by: Sunil Khatri <sunil.khatri@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
This was supposed to loop over the individual evicted list, as the
kernel and always_valid evicted lists were already handled in
amdgpu_vm_validate.
Without this, BOs that were created and evicted before a userq was made
would never end up in an eviction fence rearm.
Also add the missing ref to the BO before drm_exec locks and refs it.
Fixes: 4cdbba5a16aa ("drm/amdgpu: restructure VM state machine v4")
Signed-off-by: Benjamin Cheng <benjamin.cheng@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Set vm_manager.spm_vmid to the top GFXHUB VMID so the SPM reservation
path hands out a fixed, isolated VMID on gfx8 instead of borrowing one
from the graphics pool.
Signed-off-by: Sunil Khatri <sunil.khatri@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Set vm_manager.spm_vmid to the top GFXHUB VMID so the SPM reservation
path hands out a fixed, isolated VMID on gfx7 instead of borrowing one
from the graphics pool.
Signed-off-by: Sunil Khatri <sunil.khatri@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
This adds the regCP_ME1_INT_STAT_DEBUG and regCP_ME2_INT_STAT_DEBUG registers that
were missing from the GC 11.0.0 headers but found in GC 11.0.3
Signed-off-by: Tom St Denis <tom.stdenis@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
The uapi documents drm_amdgpu_gem_list_handles_entry.alignment as
"physical start_addr alignment in bytes", and GEM_OP
GET_GEM_CREATE_INFO returns the same value in bytes, but
GEM_LIST_HANDLES returns tbo.page_alignment, which is in pages. For a BO
created with a 64 KiB alignment on navi31:
GET_GEM_CREATE_INFO: alignment=65536
GEM_LIST_HANDLES: alignment=16
so a user such as CRIU that recreates BOs from this list uses the wrong
alignment. Convert it to bytes.
Fixes: f9db1fc52ceb ("drm/amdgpu: Add ioctl to get all gem handles for a process")
Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
The SPM (Streaming Performance Monitor) path needs a VMID that is
isolated from other GPU contexts. Introduce vm_manager.spm_vmid to let
a GFXHUB dedicate a VMID to SPM.
When spm_vmid is set, exclude it from both the kernel-queue pool and
vmid_uq_mask_gfxhub, so neither the round-robin kernel-queue allocator
nor MES/Userqueues ever maps another context onto it.
Assisted-by: Claude:claude-sonnet-5
Signed-off-by: Sunil Khatri <sunil.khatri@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Fix the ambiguous names in amdgpu_vmid_mgr_set_vmid_mask()'s
parameters so there is no confusion.
Signed-off-by: Sunil Khatri <sunil.khatri@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Report the actual bad page count and convert the record threshold to
pages using the per-ASIC row size. Keep threshold decisions in record
units.
Signed-off-by: Xiang Liu <xiang.liu@amd.com>
Reviewed-by: Tao Zhou <tao.zhou1@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Report a bad page threshold breach only when the saved record count
exceeds the configured limit. Allow unlocking at equality to keep the
EEPROM status consistent with that boundary.
Signed-off-by: Xiang Liu <xiang.liu@amd.com>
Reviewed-by: Tao Zhou <tao.zhou1@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
The RAS core derives the bad page threshold from
con->reserved_pages_in_bytes when amdgpu_ras_mgr_sw_init() builds the
EEPROM configuration. That field is still zero at this point, so the
threshold falls back to the 16MB default and ends up at 128 pages on
ASICs that reserve 32MB.
Set the reserved vram size before RAS core sw init so the threshold is
computed from the per-ASIC value.
Signed-off-by: Xiang Liu <xiang.liu@amd.com>
Reviewed-by: Tao Zhou <tao.zhou1@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Read the feature status of RAS_CORE_FW_FEATURE_BIT_RAS_EEPROM to determine
whether to use firmware-managed EEPROM.
Signed-off-by: Ce Sun <cesun102@amd.com>
Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Build and program doorbell entry control values through the common
NBIO helpers while preserving the existing nbif v6_3_1 client
routing and field values.
Signed-off-by: Hawking Zhang <Hawking.Zhang@amd.com>
Reviewed-by: Likun Gao <Likun.Gao@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Build and program doorbell entry control values through the common
NBIO helpers while preserving the existing nbio v7_11_4 client
routing and field values.
Signed-off-by: Hawking Zhang <Hawking.Zhang@amd.com>
Reviewed-by: Likun Gao <Likun.Gao@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
nbio v7_11_4 and v7_11_5 now have dedicated implementations.
Select nbio v7_11_4 function and HDP flush tables during IP
discovery, and remove the version-specific register offsets
and doorbell handling from nbif v6_3_1.
Signed-off-by: Hawking Zhang <Hawking.Zhang@amd.com>
Reviewed-by: Likun Gao <Likun.Gao@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
RAS early init executes prior to smu_sw_init, leaving feature_num as 0
and triggering invalid bitmap operations.
Signed-off-by: Ce Sun <cesun102@amd.com>
Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Only the mode that halts runtime services flags the device once the bad
page threshold is reached, so on a default or warn-only threshold the
in-band CPER record and the out-of-band RMA reason are not emitted even
though the table records that the threshold was hit.
Track the threshold condition separately from the halt decision and use
it to drive the report, so every mode except the debug one tells the
host that the device reached its bad page budget.
Signed-off-by: Xiang Liu <xiang.liu@amd.com>
Reviewed-by: Tao Zhou <tao.zhou1@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
The EEPROM table is tagged as over threshold while the new bad page
records are written out, so the table status queried while the records
are only queued still reports the table as writable. The device is
therefore never flagged as having reached the threshold and neither the
in-band CPER record nor the out-of-band RMA reason is emitted.
Re-evaluate the table status once the records have been appended, so the
report is driven by the state that was just persisted.
Signed-off-by: Xiang Liu <xiang.liu@amd.com>
Reviewed-by: Tao Zhou <tao.zhou1@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
In hqd_dump function
Signed-off-by: Harish Kasiviswanathan <Harish.Kasiviswanathan@amd.com>
Reviewed-by: Lijo Lazar <lijo.lazar@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
nbio v7_11_4 uses different bif doorbell port registers than
nbif v6_3_1, and different HDP flush and memory coherency
registers than nbio v7_11_5.
Signed-off-by: Hawking Zhang <Hawking.Zhang@amd.com>
Reviewed-by: Likun Gao <Likun.Gao@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Add header files for nbif v4_10_0 register offsets
and shift masks
These register definitions are derived from nbif
v6_3_1 source file which uses the _nbif_4_10 suffix
Signed-off-by: Hawking Zhang <Hawking.Zhang@amd.com>
Reviewed-by: Likun Gao <Likun.Gao@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Describe the nbio v7_11_5 S2A doorbell layout and
existing client-to-port mappings, then build and
program the CP, RLC, IH, SDMA, and VPE entries
through the common NBIO helpers.
Signed-off-by: Hawking Zhang <Hawking.Zhang@amd.com>
Reviewed-by: Likun Gao <Likun.Gao@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Describe the nbio v7_9 S2A doorbell layout and
client-to-port mappings, then build and program
the IH, SDMA, and VCN entries through the common
NBIO helpers.
Signed-off-by: Hawking Zhang <Hawking.Zhang@amd.com>
Reviewed-by: Likun Gao <Likun.Gao@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Some NBIO generations expose doorbell control register
instances through global SMN addresses. Extend the common
doorbell entry description and programming helper to
select this access path
The IP-specific mapping records the target register
instance while callers remain responsible for invoking
their doorbell callback for each required instance.
Signed-off-by: Hawking Zhang <Hawking.Zhang@amd.com>
Reviewed-by: Likun Gao <Likun.Gao@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Build and program the CP, RLC, IH, SDMA, and VCN
doorbell entries through the common NBIO helpers
while retaining the existing callback interface
and v4_3 client routing values.
Signed-off-by: Hawking Zhang <Hawking.Zhang@amd.com>
Reviewed-by: Likun Gao <Likun.Gao@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Describe the nbio v4_3 doorbell entry ctrl
field layout and initialize the CP, IH, SDMA,
RLC, and VCN port and register assignments.
Signed-off-by: Hawking Zhang <Hawking.Zhang@amd.com>
Reviewed-by: Likun Gao <Likun.Gao@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Build doorbell_entry_ctrl and doorbell_entry_ctrl1
values through the common field helper while retaining
the existing nbio callback interface and preserving
nbio v6_3_2 client routing values.
Signed-off-by: Hawking Zhang <Hawking.Zhang@amd.com>
Reviewed-by: Likun Gao <Likun.Gao@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
When a debugged process exits, kfd_process_notifier_release_internal()
first removes it from kfd_processes_table and then calls
kfd_dbg_trap_disable(), which drains the process interrupts. The drain
sends a fence through the IH and waits, without a timeout, for
kfd_process_close_interrupt_drain() to wake it up. That wakeup looks
the process up by PASID in kfd_processes_table, which no longer holds
it, so the wakeup is lost and the exiting task sleeps forever. The
fatal signal has already been consumed in do_exit(), so the
interruptible wait cannot be broken either.
The wait happens inside the mmu_notifier release callback, i.e. within
the global mmu_notifier SRCU read-side critical section, so every
synchronize_srcu() on it stalls as well. Any other process releasing
its mm then hangs in D state and the system needs a reboot. This is
seen with rocgdb on MI300X.
Fix this by:
- Waiting on a completion in struct amdgpu_fpriv, looked up by PASID
through amdgpu_pasid_xa, instead of looking the process up in
kfd_processes_table. The DRM file owning the PASID is still
referenced by KFD while it drains, so the drain fence always finds
its waiter. The drain logic moves to amdgpu_ids.c and KFD only
passes the PASID.
- Bounding the wait with a timeout, since the fence can be lost when
the IH ring or the KFD interrupt FIFO overflows, and warning when the
drain does not complete.
- Passing drain_irqs to kfd_dbg_trap_disable() and skipping the drain
when the process itself exits. Its interrupts are no longer delivered
once it is out of kfd_processes_table, and its PASID owner is cleared
before the PASID is freed and later reallocated cyclically.
v2: track drains with a completion in amdgpu_fpriv via amdgpu_pasid_xa
and move the drain logic to amdgpu_ids.c; pass drain_irqs to
kfd_dbg_trap_disable() and skip the drain on process exit instead
of deferring it (Felix)
v3: use AMDGPU_FENCE_JIFFIES_TIMEOUT for the drain timeout; drop
kfd_process_close_interrupt_drain() and call
amdgpu_pasid_drain_irq_done() directly from the interrupt handlers
(Felix)
Fixes: 12fb1ad70d65 ("drm/amdkfd: update process interrupt handling for debug events")
Signed-off-by: Heng Zhou <Heng.Zhou@amd.com>
Reviewed-by: Felix Kuehling <felix.kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Describe nbio v6_3_2 doorbell_entry_ctrl and
doorbell_entry_ctrl1 field layout from IP register
header and initialize gc, ih, vcn, and sdma
port and register assignments.
Signed-off-by: Hawking Zhang <Hawking.Zhang@amd.com>
Reviewed-by: Likun Gao <Likun.Gao@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Add doorbell layout and field descriptions together
with common helpers to build and program nbio
doorbell entries.
Signed-off-by: Hawking Zhang <Hawking.Zhang@amd.com>
Reviewed-by: Likun Gao <Likun.Gao@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
CP resume through MMIO programming is no longer
supported on GFX 12.0 and later generations. Remove
this obsolete code to prevent it from being carried
forward into future GFX generations.
Signed-off-by: Hawking Zhang <Hawking.Zhang@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
amdgpu_cs_parser_bos() allocates an HMM range for every userptr entry of
the BO list and looks up the user pages. Those ranges are only freed when
amdgpu_cs_parser_bos() itself fails or when amdgpu_cs_submit() checks
them under the notifier lock. If amdgpu_cs_patch_jobs(),
amdgpu_cs_vm_handling(), amdgpu_cs_sync_rings() or the early part of
amdgpu_cs_submit() fails, nothing frees them: neither
amdgpu_cs_parser_fini() nor amdgpu_bo_list_free() touch e->range.
Each such CS then leaks the range, its hmm_pfns array (8 bytes per page
of the userptr BO) and the BO reference the range holds. An IB on a ring
that patches the CS in place (e.g. VCN) with an unmapped va_start fails
in amdgpu_cs_patch_ibs() and takes this path.
Free the ranges on those error paths. Ranges amdgpu_cs_submit() already
dropped are NULL, so freeing them again is a no-op.
Fixes: fec8fdb54e8f ("drm/amdgpu: fix userptr HMM range handling v2")
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>
|
|
amdgpu_debugfs_gpr_read() drops its runtime PM reference right after
reading the wave registers. When copying them to userspace fails, it
jumps to the err label, which drops the reference a second time. A read
into a bad buffer on Navi31 either steals a reference somebody else
holds (power/runtime_usage goes from 1 to 0) or underflows the count:
amdgpu 0000:03:00.0: Runtime PM usage count underflow!
The registers are already in the kernel buffer at that point, so finish
the hardware access first and copy the buffer with a single
copy_to_user() instead of the put_user() loop with its own error path.
Fixes: 9eee152aab56 ("drm/amdgpu/debugfs: fix ref count leak when pm_runtime_get_sync fails")
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>
|
|
With RRS Software Visibility, pci_dev_wait() considers a device ready as
soon as reading the Vendor ID doesn't return the RRS value. Devices aren't
required to respond with RRS while they aren't ready, so the read may
return ~0 and pci_dev_wait() stops waiting too early. This was seen with
Intel [8086:0a54] and Samsung [144d:a80c] NVMe SSDs.
Also wait while the Vendor ID reads ~0. A VF's Vendor ID always reads ~0,
so check its Command register instead, as is done without RRS SV.
Fixes: d591f6804e7e ("PCI: Wait for device readiness with Configuration RRS")
Link: https://lore.kernel.org/r/20250611101442.387378-1-hui.wang@canonical.com
Suggested-by: Lukas Wunner <lukas@wunner.de>
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Alexander Gruhlke <gruhlke@mailbox.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Lukas Wunner <lukas@wunner.de>
Link: https://patch.msgid.link/20261011190145.23621-3-gruhlke@mailbox.org
|
|
The Samsung 990 PRO [144d:a80c] advertises Immediate Readiness, so
pcie_flr() doesn't wait after FLR, but the drive returns ~0 for up to 7 ms.
Since commit 10baa9b4df40 ("PCI: Drop unnecessary retries when restoring
BARs"), the config restore after FLR is lost, which breaks VFIO passthrough
of the drive. Firmware 8B2QJXD7 responds right after FLR, but older
firmware such as 1B2QJXD7 doesn't, and the firmware version isn't visible
here.
Ignore Immediate Readiness on this device, so pcie_flr() waits.
Fixes: 10baa9b4df40 ("PCI: Drop unnecessary retries when restoring BARs")
Link: https://bbs.archlinux.org/viewtopic.php?id=314833
Link: https://lore.kernel.org/r/20261010160529.27974-1-gruhlke@mailbox.org
Suggested-by: Lukas Wunner <lukas@wunner.de>
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Alexander Gruhlke <gruhlke@mailbox.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Lukas Wunner <lukas@wunner.de>
Link: https://patch.msgid.link/20261011190145.23621-2-gruhlke@mailbox.org
|
|
Vladyslav Tymoshchuk <tvlad744@gmail.com> says:
Since commit a93dad6f4e6a ("ASoC: q6apm-dai: make use of
q6apm_get_hw_pointer") q6apm-dai reports one frame less than the
position of the last buffer the DSP returned, and commit 44432315444c
("ASoC: qcom: q6asm-dai: use q6asm_get_hw_pointer") did the same in
q6asm-dai. When the application stops feeding a playback stream, the
position never reaches appl_ptr: ALSA never sees the underrun, the
stream stays RUNNING without period interrupts, and drain ends on its
timeout with -EIO. On a OnePlus Pad 3 (SM8750) this left PipeWire's
PCM stuck for hours after a stall.
Patch 1 wraps the q6apm position to 0 at the end of the ring, as before
a93dad6f4e6a. Patch 2 resets the q6apm hw pointer on prepare, which
a93dad6f4e6a also stopped doing. Patch 3 is patch 1 for q6asm-dai.
Patches 1 and 2 are tested on SM8750 (numbers in patch 1). Patch 3 is
compile-tested only; a test on a Q6ASM board (RB3, RB5) and on x1e or
sc8280xp for patches 1 and 2 would be very welcome.
The RFC "ASoC: qcom: q6apm: correct PCM formats and error handling" by
Zhang Jiaxi [1] touches the same hw pointer, in graph_callback() (4/4
"recover PCM from failed data receipts"). The two do not conflict:
that series changes when the hw pointer is published, this one how it
is turned into a position and when it is reset, and that series
applies on top of this one on sound/for-next without conflicts.
The analysis, the patches and this text were drafted with an AI
assistant (Claude, see Assisted-by); I reviewed them and ran the tests
described in the patches.
[1] https://lore.kernel.org/r/SY5PR01MB10600B2BE812BAA1B0FA501B4A1932@SY5PR01MB10600.ausprd01.prod.outlook.com
Link: https://patch.msgid.link/20261014162703.10172-1-tvlad744@gmail.com
|
|
Commit 44432315444c ("ASoC: qcom: q6asm-dai: use q6asm_get_hw_pointer")
took the position from the number of period buffers the DSP has
returned in the current lap, 1..periods, and reports one frame less
than that, as q6apm-dai does.
One frame short, a playback stream whose application stops feeding it
never reaches the stop threshold: the DSP returns the last queued
buffer, the position stops at appl_ptr - 1 and no period interrupt
comes any more, so ALSA never detects the underrun, the stream stays
RUNNING and drain only ends on its timeout. On capture, the last frame
of each period is held back until the next one.
Before that commit the position wrapped to 0 at the end of the ring.
Do that again, as for q6apm-dai.
Fixes: 44432315444c ("ASoC: qcom: q6asm-dai: use q6asm_get_hw_pointer")
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Vladyslav Tymoshchuk <tvlad744@gmail.com>
Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
Tested-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
Link: https://patch.msgid.link/20261014162703.10172-4-tvlad744@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
On every prepare in queue mode, q6apm_dai_prepare() frees and allocates
the fragments again, and q6apm_alloc_fragments() resets dsp_buf, so the
first buffer queued after it is the first one of the ring. The hw
pointer that q6apm_dai_pointer() reports is left as it was.
q6apm-dai used to keep its own position and cleared it in prepare.
Since commit a93dad6f4e6a ("ASoC: q6apm-dai: make use of
q6apm_get_hw_pointer") the position comes from the hw pointer, so a
stream that is prepared again, e.g. to recover from an xrun, reports
the position of the previous run until the DSP returns its first
buffer, while ALSA has reset its own pointer to 0.
Reset the hw pointer together with dsp_buf.
Fixes: a93dad6f4e6a ("ASoC: q6apm-dai: make use of q6apm_get_hw_pointer")
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Vladyslav Tymoshchuk <tvlad744@gmail.com>
Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
Tested-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
Link: https://patch.msgid.link/20261014162703.10172-3-tvlad744@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
q6apm_dai_pointer() turns the number of period buffers the DSP has
returned in the current lap, 1..periods, into a position and reports
one frame less than that. Commit a93dad6f4e6a ("ASoC: q6apm-dai: make
use of q6apm_get_hw_pointer") added the "- 1" so that the end of the
ring is not reported as a position equal to the buffer size.
One frame short has a cost once the application stops feeding the
stream. The DSP returns the last queued buffer and the position stops
at appl_ptr - 1, so avail stays at buffer_size - 1, below the default
stop_threshold. The DSP sends nothing more as its queue is empty, so
no period interrupt comes either: ALSA never detects the underrun and
the stream stays RUNNING. A poll-driven application that missed its
last wakeup waits forever, and drain only ends on its timeout, with
-EIO. On capture, the last frame of each period is held back until
the next one.
Before that commit the position wrapped to 0 at the end of the ring.
Do that again. A full lap is the start of the ring, and
snd_pcm_update_hw_ptr0() accounts for the wrap: the position cannot
move by more than one lap between two updates, as each returned buffer
calls snd_pcm_period_elapsed() and the DSP holds at most periods
buffers.
Seen on a OnePlus Pad 3 (SM8750) with PipeWire in interrupt-driven
scheduling: after a stall the PCM sat at hw_ptr 78239, appl_ptr 78240
(avail 3839 of 3840) for two hours.
Fixes: a93dad6f4e6a ("ASoC: q6apm-dai: make use of q6apm_get_hw_pointer")
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Vladyslav Tymoshchuk <tvlad744@gmail.com>
Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
Tested-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
Link: https://patch.msgid.link/20261014162703.10172-2-tvlad744@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
This version brings along the following updates:
- Refactor DC IP request control in HWSS.
- Fix rotate 90 degrees surface corruption issue.
- Refactor DPP root clock control in HWSS.
- Fix upsampling and linear scaling.
- Use aux hw inst if no ddc pin exists.
- Directly include compiler_attributes.h.
- Fix frac_urg_bw conversion to correct U0.10 format.
- Do full link training during HDR/SDR seamless switch.
- Fix SPL format handling for linear scaling and upsampling.
- Update DCN42 cstate latencies.
- Invalidate the DRR shadow after a hardware re-init.
- Program HDR visual confirm based on per pipe info.
- Split link_set_dsc_on_stream into encoder and DSC components.
- Add new config_dsc hwseq function for DCN60.
- Program DSC prior to OTG enable starting DCN60.
- Improve mandatory pstate optimization and check.
- Disable HUBP/DPP power gating on DCN42.
Acked-by: Leo Li <sunpeng.li@amd.com>
Signed-off-by: Taimur Hassan <Syed.Hassan@amd.com>
Signed-off-by: Ivan Lipski <ivan.lipski@amd.com>
Tested-by: Dan Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
[Why]
Driver-controlled HUBP and DPP power gating can cause display underflow
on DCN42.
[How]
Set disable_hubp_power_gate and disable_dpp_power_gate in the DCN42
driver debug defaults as a temporary workaround.
Reviewed-by: Ovidiu (Ovi) Bunea <ovidiu.bunea@amd.com>
Signed-off-by: Leo Chen <leo.chen@amd.com>
Signed-off-by: Ivan Lipski <ivan.lipski@amd.com>
Tested-by: Dan Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
[WHY&HOW]
Improves the optimization heuristic for "ideal" disallow time to clamp
to a number more likely to pass the mandatory pstate checks.
Fixes core calculations to account for reserved time when considering
the allow time for mandatory pstate checks.
Reviewed-by: Austin Zheng <austin.zheng@amd.com>
Signed-off-by: Dillon Varone <Dillon.Varone@amd.com>
Signed-off-by: Ivan Lipski <ivan.lipski@amd.com>
Tested-by: Dan Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
[Why]
Current DSC enable sequence is intertwined with the DPMS on sequence.
The sequence has become unnecessarily confusing, and resulted in cases
where DSC is programmed unexpectedly, or in an incorrect sequence.
Current sequence enables OTG before DSC. After discussing with HW team,
there should be no issue with enabling DSC first before OTG.
[How]
Starting with DCN60, skip DSC HW programming in the DPMS sequences.
Add enable DSC function call prior to OTG enable, and similarly for the
disable case.
Reviewed-by: Dillon Varone <dillon.varone@amd.com>
Signed-off-by: George Shen <george.shen@amd.com>
Signed-off-by: Ivan Lipski <ivan.lipski@amd.com>
Tested-by: Dan Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
[Why]
The current DSC block programming sequence is intertwined with the
stream encoder DSC-related programming. Logically, the programming of
the DSC (front end) and stream encoder (back end) blocks should be
independent of each other.
[How]
Create a new hwseq function config_dsc to handle the DSC block
programming sequence.
Reviewed-by: Dillon Varone <dillon.varone@amd.com>
Signed-off-by: George Shen <george.shen@amd.com>
Signed-off-by: Ivan Lipski <ivan.lipski@amd.com>
Tested-by: Dan Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
[Why]
DSC block programming should be independent from link programming. This
should be refactored such that DSC block programming is in HWSS.
[How]
The first step to the refactor is to split the existing logic into the
encoder portion and the DSC block portion.
Reviewed-by: Dillon Varone <dillon.varone@amd.com>
Signed-off-by: George Shen <george.shen@amd.com>
Signed-off-by: Ivan Lipski <ivan.lipski@amd.com>
Tested-by: Dan Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
[Description]
HDR visual confirm should be programmed based on per-pipe info, not
top pipe info. There exists scenarios where an HDR app has a desktop
plane still active (due to SW cursor) which is ARGB8888. Taking the top
pipe info will give the wrong visual confirm color.
Reviewed-by: Aric Cyr <aric.cyr@amd.com>
Signed-off-by: Alvin Lee <Alvin.Lee2@amd.com>
Signed-off-by: Ivan Lipski <ivan.lipski@amd.com>
Tested-by: Dan Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
[Why]
dc_stream_adjust_vmin_vmax() skips hardware programming when
stream->adjust already matches the request and timing_adjust_pending is
clear. That treats stream->adjust as a faithful shadow of the OTG, but
dc_set_power_state(D0) calls init_hw(),
which returns OTG_V_TOTAL_MIN/MAX and the static screen triggers to
their reset defaults without touching any stream. After an S3/S4 resume
or a GPU reset the shadow claims hardware is current when it is not.
A resume that reuses the same stream object also short-circuits
dc_commit_streams() on !streams_changed(), so enable_stream_timing()
never runs either and nothing reprograms DRR. Replay then fails to arm:
the static screen trigger is at its reset value and the coasting vtotal
no longer matches the OTG.
The max_v_total overflow path has a second problem. When OTG v_count
halt is not allowed it stores the new values and marks the adjustment
pending even though nothing was programmed, and no later call with the
same values can clear that flag.
[How]
Add invalidate_drr_adjust() to mark every stream in current_state as
having a pending timing adjustment, and call it once hardware has been
re-initialized in dc_set_power_state(),
so the next dc_stream_adjust_vmin_vmax() reprograms the OTG.
Hoist the max_v_total check above the point where stream->adjust is
updated and return early when v_count halt is not allowed, leaving the
shadow describing the OTG instead of latching a flag nothing can clear.
On the paths that do update stream->adjust, set the flag up front and
clear it only after set_long_vtotal() or set_drr() has actually run.
Reviewed-by: Josip Pavic <josip.pavic@amd.com>
Signed-off-by: Aric Cyr <Aric.Cyr@amd.com>
Signed-off-by: Ivan Lipski <ivan.lipski@amd.com>
Tested-by: Dan Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
[WHY]
New cstate exit latency measurements from DCN IPSE for DCN42.
[HOW]
Update stutter latencies in the DCN42 soc bb:
- LPDDR5: exit 13.5us, enter plus exit 15.5us
- DDR5: exit 23.0us, enter plus exit 25.0us
Pstate change latency is already 36us for both.
Reviewed-by: Austin Zheng <austin.zheng@amd.com>
Signed-off-by: Ovidiu Bunea <ovidiu.bunea@amd.com>
Signed-off-by: Ivan Lipski <ivan.lipski@amd.com>
Tested-by: Dan Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
