[FROM-ML] drm/amd/display: VRR fixes, HDMI Gaming Features v3#4
Merged
KyleGospo merged 19 commits intoogc-6.19.yfrom Feb 13, 2026
Merged
[FROM-ML] drm/amd/display: VRR fixes, HDMI Gaming Features v3#4KyleGospo merged 19 commits intoogc-6.19.yfrom
KyleGospo merged 19 commits intoogc-6.19.yfrom
Conversation
KyleGospo
changed the title
|
@KyleGospo this is already outdated: https://lists.freedesktop.org/archives/amd-gfx/2026-February/138119.html |
Member
Author
Thanks, I'll update this PR |
|
Seems we need more patches backported to make the newer version work. At least on the upstream 6.18.x series. |
|
Most likely the new series works with 6.19.x series ... |
|
Here are some patches I added so far on top of 6.18.10: AerynOS/recipes@a682588 |
Member
Author
|
@hphilm 6.19 just hit stable so I will update this to the new series |
Member
Author
|
@hphilm Rebased, now v3 and for 6.19.0 |
…_vsdb() [Why] The function would continue to try to parse EDID even if DisplayID extension block wasn't found. Sometimes it got lucky and found AMD vsdb in CEA extension block which made debugging harder. [How] Add a return if DisplayID extension block wasn't found Signed-off-by: Tomasz Pakuła <tomasz.pakula.oficjalny@gmail.com>
[Why] This function started to get very messy and hard to follow. [How] Eject some functionality to separate functions and simplify greatly. Changes in v3: - Less struct traversal in helper functions Signed-off-by: Tomasz Pakuła <tomasz.pakula.oficjalny@gmail.com>
[Why] Some monitors only expose GTF ranges (or others, without Range Limits Only flag). This breaks VRR even though they have explicit FreeSync support. Currently, if monitor ranges were missing, amdgpu only searched for AMD vsdb in DisplayID but many monitors have it in CEA, just like HDMI. [How] For DP and eDP connections, check for VRR ranges provided in AMD vendor- specific data block if VRR range wasn't detected. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3894 Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4457 Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4747 Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4856 Signed-off-by: Tomasz Pakuła <tomasz.pakula.oficjalny@gmail.com>
[Why] Some monitors only expose their full VRR range in AMD vsdb for some reason. [How] Compare exposed ranges and use the bigger one. This check could be merged with the previous one but it's better to keep them separate to easily convey their meaning. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4177 Signed-off-by: Tomasz Pakuła <tomasz.pakula.oficjalny@gmail.com>
[Why] DP->HDMI PCONs prevously entered the DP path [How] Restructure amdgpu_dm_update_freesync_caps() and move dm_get_adaptive_sync_support_type() to dm_helpers_is_vrr_pcon_allowed() to better reflect what this function does. It never actually gave us any other info. Signed-off-by: Tomasz Pakuła <tomasz.pakula.oficjalny@gmail.com>
[Why] It's currently very hard to test if a random PCON supports VRR and report it's ID. [How] Adds override as part of dc debug mask. Allows faster testing and reporting of VRR-compatible DP->HDMI adapters. Signed-off-by: Tomasz Pakuła <tomasz.pakula.oficjalny@gmail.com>
[Why] Chrontel CH7218 found in Ugreen DP -> HDMI 2.1 adapter (model 85564) works perfectly with VRR after testing. VRR and FreeSync compatibility is explicitly advertised as a feature so it's addition is a formality. Support FreeSync info packet passthrough and "generic" HDMI VRR. [How] Add CH7218's ID to dm_helpers_is_vrr_pcon_allowed() Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4773 Signed-off-by: Tomasz Pakuła <tomasz.pakula.oficjalny@gmail.com>
[Why] Drivers may need info about gaming features exposed by HDMI sinks. Add a central way of storing this information. [How] Adds flags and a struct to hold HDMI VRR information. `supported` here is an additional property which allows easier parsing in consumers and adds a bit of logic used to detect malformed VRRmin/VRRmax values. Signed-off-by: Tomasz Pakuła <tomasz.pakula.oficjalny@gmail.com> Tested-by: Bernhard Berger <bernhard.berger@gmail.com>
[Why] PCONs support sending out HDMI VRR infopackets on their own and this makes this types not specific to FreeSync [How] Make the name more generic for the upcoming HDMI VRR over PCON implementation Signed-off-by: Tomasz Pakuła <tomasz.pakula.oficjalny@gmail.com> Tested-by: Bernhard Berger <bernhard.berger@gmail.com>
[Why] Not all TVs support FreeSync and many TVs suffer from VRR flickering while Freesync is activated. [How] This works the same as FreeSync over PCON just without sending FreeSync info packets (we're sending standard DisplayPort info packets) + reading the VRR range from the HDMI Forum vendor specific data block. PCONs take over HDMI VRR triggering. Prefer HDMI VRR over FreeSync to reduce VRR flickering on many TVs. FreeSync over HDMI seems to be a fallback solution and not a first-class citizen. This especially helps VMM7100. Tested with VMM7100 and CH7218 based adapters on multiple HDMI 2.1 and HDMI 2.0 devices. (Samsung S95B, LG C4, Sony Bravia 8, Dell AW3423DWF) Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4805 Signed-off-by: Tomasz Pakuła <tomasz.pakula.oficjalny@gmail.com> Tested-by: Bernhard Berger <bernhard.berger@gmail.com>
[Why] VRRmax=0 is a valid value and means that the upper bound is guared by the selected video mode. [How] In this context, saved vrr max is the max possible refresh rate ever. Try getting upper VRR bound from AMD vsdbif it exists or rely on the limitations of BRR in VTEM info frames. I found through testing, that TVs seem to reject VTEM when BRR is set to over 1023 Hz. Use this as the last resort VRRmax. 1023 is the max value for a 10-bit field as well. v2: - Update max BRR value to 1023 Signed-off-by: Tomasz Pakuła <tomasz.pakula.oficjalny@gmail.com>
[Why] HDMI vsif was assigned to vsp_infopacket (FreeSync) field [How] Build HDMI vsif in the correct hfvsif_infopacket field Signed-off-by: Tomasz Pakuła <tomasz.pakula.oficjalny@gmail.com>
[Why] We need info about these features in parts of the driver where fishing for drm_connector struct is infeasible. [How] Add three new fields to dc_edid_caps and fill them if connected device is HDMI based on it's EDID Signed-off-by: Tomasz Pakuła <tomasz.pakula.oficjalny@gmail.com>
[Why] Support for triggering ALLM in modern TVs is missing. When HDMI vsif was added in 2019: commit 3c2381b ("drm/amd/display: add support for VSIP info packet") it was improperly handeled as HDMI actually has two separate vsifs. The implementation was based on H14b-vsif and ALLM bit was messing it up because H14b-vsif doesn't support ALLM. It was later removed in: commit 75f77aa ("drm/amd/display: Send H14b-VSIF specified in HDMI") ALLM is supported by hf-vsif (HDMI Forum) instead. [How] Add proper logic to construct either h14b-vsif or hf-vsif based on required capabilities. Currently, only ALLM from hf-vsif is supported. Turns out, hf-vsif is almost identical to h14b-vsif, BUT has additional two bytes of data after OUI. First byte is static and seems like a version supported by leftover define. Second byte consists of 3D and ALLM bits. Implement logic to offset 3D data if building hf-vsif. Signed-off-by: Tomasz Pakuła <tomasz.pakula.oficjalny@gmail.com>
[Why] ALLM automatically puts TVs into low latency modes (gaming modes) which we basically always want for PC use, be it gaming, or using precise inputs like mice and keyboards. [How] Read the ALLM info from HDMI caps and use it to determine if ALLM should be indicated in HDMI Forum vsif. Additionally, make sure VIC modes are translated in case of ALLM active as VIC cannot be used in conjunction with hf-vsif. I learned this the hard way... Signed-off-by: Tomasz Pakuła <tomasz.pakula.oficjalny@gmail.com>
[Why] Some users prefer to always manually control ALLM/Gaming mode while others might want it permanently forced on. [How] Since there isn't yet an API to control this, expose module parameter Changes in v3: - Include a fix for possible NULL pointer dereference by Peter Closes: CachyOS/linux-cachyos#680 Co-developed-by: Peter Jung <admin@ptr1337.dev> Signed-off-by: Peter Jung <admin@ptr1337.dev> Signed-off-by: Tomasz Pakuła <tomasz.pakula.oficjalny@gmail.com>
[Why] VTEM info fram building was removed back in: commit a9f54ce ("drm/amd/display: Refactoring VTEM"), but it's needed to support HDMI VRR signalling. [How] Build completely new and more robust functions to build out the VTEM infopacket. Many values are defined but could have added logic in the future, that's shy they are not static values but already value + bit position in it's byte. Reduced blanking detection was previously missing. Use possible hblank periods defined for RB1 (from CVT 1.2), RB2 and RB3 (from CVT 2.1). Changes in v3: - Use div_u64() instead of division operator Signed-off-by: Tomasz Pakuła <tomasz.pakula.oficjalny@gmail.com>
[Why] We'd like to expose VRR functionality to end user if HDMI sink is advertising it's support. [How] VTEM info frame is used to signal HDMI sink that VRR is active. Use VTEM info packet as vrr_infopacket Signed-off-by: Tomasz Pakuła <tomasz.pakula.oficjalny@gmail.com>
[Why] Many TVs and other HDMI sinks suffer from blanking and possibly other glitches when VRR is toggled. With FreeSync present on such sinks, they behave like the signal is always variable, even in fixed refresh rate situations. [How] Keep HDMI VRR toggled if it's supported and not explicitly disabled. Additionnally, add module parameter which allows users to configure HDMI VRR triggering to only happen when the signal is truly asking for variable state. This is useful if end user has a TV that automatically toggles ALLM/Game mode when VRR is active and such user doesn't want gaming mode in normal desktop usage. Signed-off-by: Tomasz Pakuła <tomasz.pakula.oficjalny@gmail.com>
KyleGospo
changed the title
Member
Author
|
@pastaq should be up to standard now |
KyleGospo
changed the title
pastaq
approved these changes
Feb 13, 2026
|
LGTM |
pull bot
pushed a commit
that referenced
this pull request
Feb 27, 2026
The ETM decoder incorrectly assumed that auxtrace queue indices were
equivalent to CPU number. This assumption is used for inserting records
into the queue, and for fetching queues when given a CPU number. This
assumption held when Perf always opened a dummy event on every CPU, even
if the user provided a subset of CPUs on the commandline, resulting in
the indices aligning.
For example:
# event : name = cs_etm//u, , id = { 2451, 2452 }, type = 11 (cs_etm), size = 136, config = 0x4010, { sample_period, samp>
# event : name = dummy:u, , id = { 2453, 2454, 2455, 2456 }, type = 1 (PERF_TYPE_SOFTWARE), size = 136, config = 0x9 (PER>
0 0 0x200 [0xd0]: PERF_RECORD_ID_INDEX nr: 6
... id: 2451 idx: 2 cpu: 2 tid: -1
... id: 2452 idx: 3 cpu: 3 tid: -1
... id: 2453 idx: 0 cpu: 0 tid: -1
... id: 2454 idx: 1 cpu: 1 tid: -1
... id: 2455 idx: 2 cpu: 2 tid: -1
... id: 2456 idx: 3 cpu: 3 tid: -1
Since commit 811082e ("perf parse-events: Support user CPUs mixed
with threads/processes") the dummy event no longer behaves in this way,
making the ETM event indices start from 0 on the first CPU recorded
regardless of its ID:
# event : name = cs_etm//u, , id = { 771, 772 }, type = 11 (cs_etm), size = 144, config = 0x4010, { sample_period, sample>
# event : name = dummy:u, , id = { 773, 774 }, type = 1 (PERF_TYPE_SOFTWARE), size = 144, config = 0x9 (PERF_COUNT_SW_DUM>
0 0 0x200 [0x90]: PERF_RECORD_ID_INDEX nr: 4
... id: 771 idx: 0 cpu: 2 tid: -1
... id: 772 idx: 1 cpu: 3 tid: -1
... id: 773 idx: 0 cpu: 2 tid: -1
... id: 774 idx: 1 cpu: 3 tid: -1
This causes the following segfault when decoding:
$ perf record -e cs_etm//u -C 2,3 -- true
$ perf report
perf: Segmentation fault
-------- backtrace --------
#0 0xaaaabf9fd020 in ui__signal_backtrace setup.c:110
#1 0xffffab5c7930 in __kernel_rt_sigreturn [vdso][930]
#2 0xaaaabfb68d30 in cs_etm_decoder__reset cs-etm-decoder.c:85
#3 0xaaaabfb65930 in cs_etm__get_data_block cs-etm.c:2032
#4 0xaaaabfb666fc in cs_etm__run_per_cpu_timeless_decoder cs-etm.c:2551
#5 0xaaaabfb6692c in (cs_etm__process_timeless_queues cs-etm.c:2612
#6 0xaaaabfb63390 in cs_etm__flush_events cs-etm.c:921
#7 0xaaaabfb324c0 in auxtrace__flush_events auxtrace.c:2915
#8 0xaaaabfaac378 in __perf_session__process_events session.c:2285
#9 0xaaaabfaacc9c in perf_session__process_events session.c:2442
#10 0xaaaabf8d3d90 in __cmd_report builtin-report.c:1085
#11 0xaaaabf8d6944 in cmd_report builtin-report.c:1866
#12 0xaaaabf95ebfc in run_builtin perf.c:351
#13 0xaaaabf95eeb0 in handle_internal_command perf.c:404
#14 0xaaaabf95f068 in run_argv perf.c:451
#15 0xaaaabf95f390 in main perf.c:558
#16 0xffffaab97400 in __libc_start_call_main libc_start_call_main.h:74
#17 0xffffaab974d8 in __libc_start_main@@GLIBC_2.34 libc-start.c:128
#18 0xaaaabf8aa8f0 in _start perf[7a8f0]
Fix it by inserting into the queues based on CPU number, rather than
using the index.
Fixes: 811082e ("perf parse-events: Support user CPUs mixed with threads/processes")
Signed-off-by: James Clark <james.clark@linaro.org>
Tested-by: Leo Yan <leo.yan@arm.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: coresight@lists.linaro.org
Cc: Ian Rogers <irogers@google.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: John Garry <john.g.garry@oracle.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Mike Leach <mike.leach@linaro.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Suzuki Poulouse <suzuki.poulose@arm.com>
Cc: Thomas Falcon <thomas.falcon@intel.com>
Cc: Will Deacon <will@kernel.org>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
pull bot
pushed a commit
that referenced
this pull request
Feb 27, 2026
When run on a kernel without BTF info, perf crashes:
libbpf: kernel BTF is missing at '/sys/kernel/btf/vmlinux', was CONFIG_DEBUG_INFO_BTF enabled?
libbpf: failed to find valid kernel BTF
Program received signal SIGSEGV, Segmentation fault.
0x00005555556915b7 in btf.type_cnt ()
(gdb) bt
#0 0x00005555556915b7 in btf.type_cnt ()
#1 0x0000555555691fbc in btf_find_by_name_kind ()
#2 0x00005555556920d0 in btf.find_by_name_kind ()
#3 0x00005555558a1b7c in init_numa_data (con=0x7fffffffd0a0) at util/bpf_lock_contention.c:125
#4 0x00005555558a264b in lock_contention_prepare (con=0x7fffffffd0a0) at util/bpf_lock_contention.c:313
#5 0x0000555555620702 in __cmd_contention (argc=0, argv=0x7fffffffea10) at builtin-lock.c:2084
#6 0x0000555555622c8d in cmd_lock (argc=0, argv=0x7fffffffea10) at builtin-lock.c:2755
#7 0x0000555555651451 in run_builtin (p=0x555556104f00 <commands+576>, argc=3, argv=0x7fffffffea10)
at perf.c:349
#8 0x00005555556516ed in handle_internal_command (argc=3, argv=0x7fffffffea10) at perf.c:401
#9 0x000055555565184e in run_argv (argcp=0x7fffffffe7fc, argv=0x7fffffffe7f0) at perf.c:445
#10 0x0000555555651b9f in main (argc=3, argv=0x7fffffffea10) at perf.c:553
Check if btf loading failed, and don't do anything with it in
init_numa_data(). This leads to the following error message, instead of
just a crash:
libbpf: kernel BTF is missing at '/sys/kernel/btf/vmlinux', was CONFIG_DEBUG_INFO_BTF enabled?
libbpf: failed to find valid kernel BTF
libbpf: kernel BTF is missing at '/sys/kernel/btf/vmlinux', was CONFIG_DEBUG_INFO_BTF enabled?
libbpf: failed to find valid kernel BTF
libbpf: Error loading vmlinux BTF: -ESRCH
libbpf: failed to load BPF skeleton 'lock_contention_bpf': -ESRCH
Failed to load lock-contention BPF skeleton
lock contention BPF setup failed
Signed-off-by: Tycho Andersen (AMD) <tycho@kernel.org>
Acked-by: Namhyung Kim <namhyung@kernel.org>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Chun-Tse Shao <ctshao@google.com>
Cc: Ian Rogers <irogers@google.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: James Clark <james.clark@linaro.org>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: K Prateek Nayak <kprateek.nayak@amd.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ravi Bangoria <ravi.bangoria@amd.com>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
pull bot
pushed a commit
that referenced
this pull request
Feb 27, 2026
With PREEMPT_RT as potential configuration option, spinlock_t is now
considered as a sleeping lock, and thus might cause issues when used in
an atomic context. But even with PREEMPT_RT as potential configuration
option, raw_spinlock_t remains as a true spinning lock/atomic context.
This creates potential issues with the s390 debug/tracing feature. The
functions to trace errors are called in various contexts, including
under lock of raw_spinlock_t, and thus the used spinlock_t in each debug
area is in violation of the locking semantics.
Here are two examples involving failing PCI Read accesses that are
traced while holding `pci_lock` in `drivers/pci/access.c`:
=============================
[ BUG: Invalid wait context ]
6.19.0-devel #18 Not tainted
-----------------------------
bash/3833 is trying to lock:
0000027790baee30 (&rc->lock){-.-.}-{3:3}, at: debug_event_common+0xfc/0x300
other info that might help us debug this:
context-{5:5}
5 locks held by bash/3833:
#0: 0000027efbb29450 (sb_writers#3){.+.+}-{0:0}, at: ksys_write+0x7c/0xf0
#1: 00000277f0504a90 (&of->mutex#2){+.+.}-{4:4}, at: kernfs_fop_write_iter+0x13e/0x260
#2: 00000277beed8c18 (kn->active#339){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x164/0x260
#3: 00000277e9859190 (&dev->mutex){....}-{4:4}, at: pci_dev_lock+0x2e/0x40
#4: 00000383068a7708 (pci_lock){....}-{2:2}, at: pci_bus_read_config_dword+0x4a/0xb0
stack backtrace:
CPU: 6 UID: 0 PID: 3833 Comm: bash Kdump: loaded Not tainted 6.19.0-devel #18 PREEMPTLAZY
Hardware name: IBM 9175 ME1 701 (LPAR)
Call Trace:
[<00000383048afec2>] dump_stack_lvl+0xa2/0xe8
[<00000383049ba166>] __lock_acquire+0x816/0x1660
[<00000383049bb1fa>] lock_acquire+0x24a/0x370
[<00000383059e3860>] _raw_spin_lock_irqsave+0x70/0xc0
[<00000383048bbb6c>] debug_event_common+0xfc/0x300
[<0000038304900b0a>] __zpci_load+0x17a/0x1f0
[<00000383048fad88>] pci_read+0x88/0xd0
[<00000383054cbce0>] pci_bus_read_config_dword+0x70/0xb0
[<00000383054d55e4>] pci_dev_wait+0x174/0x290
[<00000383054d5a3e>] __pci_reset_function_locked+0xfe/0x170
[<00000383054d9b30>] pci_reset_function+0xd0/0x100
[<00000383054ee21a>] reset_store+0x5a/0x80
[<0000038304e98758>] kernfs_fop_write_iter+0x1e8/0x260
[<0000038304d995da>] new_sync_write+0x13a/0x180
[<0000038304d9c5d0>] vfs_write+0x200/0x330
[<0000038304d9c88c>] ksys_write+0x7c/0xf0
[<00000383059cfa80>] __do_syscall+0x210/0x500
[<00000383059e4c06>] system_call+0x6e/0x90
INFO: lockdep is turned off.
=============================
[ BUG: Invalid wait context ]
6.19.0-devel #3 Not tainted
-----------------------------
bash/6861 is trying to lock:
0000009da05c7430 (&rc->lock){-.-.}-{3:3}, at: debug_event_common+0xfc/0x300
other info that might help us debug this:
context-{5:5}
5 locks held by bash/6861:
#0: 000000acff404450 (sb_writers#3){.+.+}-{0:0}, at: ksys_write+0x7c/0xf0
#1: 000000acff41c490 (&of->mutex#2){+.+.}-{4:4}, at: kernfs_fop_write_iter+0x13e/0x260
#2: 0000009da36937d8 (kn->active#75){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x164/0x260
#3: 0000009dd15250d0 (&zdev->state_lock){+.+.}-{4:4}, at: enable_slot+0x2e/0xc0
#4: 000001a19682f708 (pci_lock){....}-{2:2}, at: pci_bus_read_config_byte+0x42/0xa0
stack backtrace:
CPU: 16 UID: 0 PID: 6861 Comm: bash Kdump: loaded Not tainted 6.19.0-devel #3 PREEMPTLAZY
Hardware name: IBM 9175 ME1 701 (LPAR)
Call Trace:
[<000001a194837ec2>] dump_stack_lvl+0xa2/0xe8
[<000001a194942166>] __lock_acquire+0x816/0x1660
[<000001a1949431fa>] lock_acquire+0x24a/0x370
[<000001a19596b810>] _raw_spin_lock_irqsave+0x70/0xc0
[<000001a194843b6c>] debug_event_common+0xfc/0x300
[<000001a194888b0a>] __zpci_load+0x17a/0x1f0
[<000001a194882d88>] pci_read+0x88/0xd0
[<000001a195453b88>] pci_bus_read_config_byte+0x68/0xa0
[<000001a195457bc2>] pci_setup_device+0x62/0xad0
[<000001a195458e70>] pci_scan_single_device+0x90/0xe0
[<000001a19488a0f6>] zpci_bus_scan_device+0x46/0x80
[<000001a19547f958>] enable_slot+0x98/0xc0
[<000001a19547f134>] power_write_file+0xc4/0x110
[<000001a194e20758>] kernfs_fop_write_iter+0x1e8/0x260
[<000001a194d215da>] new_sync_write+0x13a/0x180
[<000001a194d245d0>] vfs_write+0x200/0x330
[<000001a194d2488c>] ksys_write+0x7c/0xf0
[<000001a195957a30>] __do_syscall+0x210/0x500
[<000001a19596cbb6>] system_call+0x6e/0x90
INFO: lockdep is turned off.
Since it is desired to keep it possible to create trace records in most
situations, including this particular case (failing PCI config space
accesses are relevant), convert the used spinlock_t in `struct
debug_info` to raw_spinlock_t.
The impact is small, as the debug area lock only protects bounded memory
access without external dependencies, apart from one function
debug_set_size() where kfree() is implicitly called with the lock held.
Move debug_info_free() out of this lock, to keep remove this external
dependency.
Acked-by: Heiko Carstens <hca@linux.ibm.com>
Signed-off-by: Benjamin Block <bblock@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
https://lists.freedesktop.org/archives/amd-gfx/2026-February/138119.html