| Age | Commit message (Collapse) | Author |
|---|
|
[Why]
The defaults eDP DSC link policy to minimize the link rate,
while the preferred policy is to minimize the lane count.
[How]
Use the minimize-lane policy by default.
Fall back to the minimize-link-rate policy when FEC is unavailable
or disabled. Update the KUnit expectation accordingly.
Assisted-by: Cursor:Claude-Opus-5.5
Reviewed-by: Tom Chung <chiahsuan.chung@amd.com>
Signed-off-by: Ray Wu <ray.wu@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
[Why & How]
The FFE electrical compliance test behavior is not correct. The driver
doesn't properly iterate over the FFE levels and select PS/DE based on
test request and/or cable-ID.
Fix the initialization of the link state so that when the polling loop
takes over, the test proceeds as described in the spec.
Reviewed-by: Relja Vojvodic <relja.vojvodic@amd.com>
Signed-off-by: Ilya Bakoulin <Ilya.Bakoulin@amd.com>
Signed-off-by: Ray Wu <ray.wu@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
The check-and-allocate sequence on pdd->qpd.proc_doorbells is
lockless at every call site of kfd_alloc_process_doorbells():
kfd_get_process_doorbells() (mmap of /dev/kfd),
kfd_ioctl_create_queue() and the CRIU restore path each test the
pointer under different locking (or none), so two racing threads can
both observe NULL and each allocate a doorbell BO and bitmap,
orphaning one allocation and handing the two mappings different
backing pages.
Move the serialization into kfd_alloc_process_doorbells() itself,
using a new per-process-device mutex so all three call sites are
covered regardless of their own locking. The device-global
kfd->doorbell_mutex is not suitable here: it is acquired under
dqm->lock on the kernel-doorbell path (start_cpsch() -> pm_init() ->
kq_initialize() -> kfd_get_kernel_doorbell()), so holding it across
the sleeping allocations above would create a lock-ordering
inversion with dqm->lock via TTM eviction, and it would also
serialize doorbell setup of unrelated processes behind a
device-wide lock for per-process state.
This issue was discovered by Tencent CodeBuddy Security.
v3 (Felix Kuehling):
- Removed unlocked check in kfd_get_process_doorbell flagged as
problematic by Sashiko Bot. Fall back to the locked check inside
kfd_alloc_process_doorbells
- Added missing mutex_destroy
v4 (Felix Kuehling):
- Removed unlocked checks around other kfd_alloc_process_doorbells calls
Fixes: 16f0013157bf ("drm/amdkfd: Allocate doorbells only when needed")
Signed-off-by: Henry Martin <bsdhenrymartin@gmail.com>
Signed-off-by: Felix Kuehling <felix.kuehling@amd.com>
Reviewed-by: Felix Kuehling <felix.kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Set the sdmax_rlcx_dummy_reg1 MQD field to 1 unconditionally in
update_mqd_sdma() for GFX 12.1. This is needed to enable processing of
the Linear Swap Wait/Signal SDMA packet on GFX 12.1.
Signed-off-by: Mukul Joshi <mukul.joshi@amd.com>
Reviewed-by: Harish Kasiviswanathan <Harish.Kasiviswanathan@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Add a dedicated SDMA MQD definition for GFX 12.1 and switch the
GFX 12.1 paths (sdma_v7_1 and kfd_mqd_manager_v12_1) to it.
No functional change.
Signed-off-by: Mukul Joshi <mukul.joshi@amd.com>
Reviewed-by: Harish Kasiviswanathan <Harish.Kasiviswanathan@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
On MacBookPros with switchable graphics, the firmware puts VRAM at MC
address 0 when the iGPU is enabled. A later post (S3 resume, GPU
reset) moves VRAM back to the VBIOS default. gmc_v8_0 reads
MC_VM_FB_LOCATION once at init and reprograms it only on SR-IOV. On
bare metal, the driver then keeps using the old layout.
vi_reset_quirks[] handles this for the MacBookPro14,3 by PCI ID:
commit b6b1d9721851 ("drm/amdgpu: reset VI ASIC on MacBookPro14,3")
Add the test that SI and CIK use: an Apple subsystem vendor and VRAM at
0. Other Polaris MacBookPros then get the same reset at load, for
example the MacBookPro13,3 if its firmware leaves VRAM at 0. These
boards are not tested.
Keep vi_reset_quirks[]. Its MacBookPro15,1 entries fix a different
failure, a module reload after S3:
commit a5be7ad8f5f0 ("drm/amdgpu: reset VI ASIC on MacBookPro15,1")
VRAM is not at 0 at that point, so the new test may not cover it.
After the reset, FB_BASE is not 0, so the new test does not fire again
on a module reload.
Only compile-tested.
Suggested-by: Alex Deucher <alexander.deucher@amd.com>
Assisted-by: Claude:claude-opus-5-5
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Maciej Kucharek <qchcio@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
On MacBookPros with switchable graphics, the firmware puts VRAM at MC
address 0 when the iGPU is enabled. A later post (S3 resume, GPU
reset) moves VRAM back to the VBIOS default. The SI fix resets and
posts the ASIC at load, so the driver uses the VBIOS layout from the
start:
"drm/amdgpu: reset SI ASIC on MacBookPros with VRAM at 0"
No MacBookPro has a CIK GPU, and no affected CIK board is known. Add
the same test to cik_need_reset_on_init(), so that SI, CIK and VI
handle this firmware layout in the same way. gmc_v7_0 reads
MC_VM_FB_LOCATION once at init and does not reprogram it. A CIK board
with VRAM at 0 therefore has the same problem as the SI boards.
After the reset, FB_BASE is not 0, so the new test does not fire again
on a module reload.
Only compile-tested.
Suggested-by: Alex Deucher <alexander.deucher@amd.com>
Assisted-by: Claude:claude-opus-5-5
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Maciej Kucharek <qchcio@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
On MacBookPros with switchable graphics, the firmware puts VRAM at MC
address 0 when the iGPU is enabled. The EFI stub enables the iGPU on
these machines through apple_set_os(). On a MacBookPro11,5 (Radeon R9
M370X, 1002:6821, subsystem 106b:0149), the driver adopts this layout
at init:
MC_VM_FB_LOCATION=0x007f0000, HDP_NONSURFACE_BASE=0
VRAM at 0x0-0x7fffffff, GART table at 0x1400000
The driver posts the ASIC again on S3 resume and after a GPU reset.
The VBIOS asic_init table then moves VRAM back to the VBIOS default:
MC_VM_FB_LOCATION=0xf47ff400, HDP_NONSURFACE_BASE=0xf4000000
gmc_v6_0 does not reprogram these registers. The GART table is then
no longer in VRAM, and the gfx ring test times out:
amdgpu: ring gfx test failed (-110)
amdgpu: resume of IP block <gfx_v6_0> failed -110
Reset and post the ASIC at driver load on Apple boards with VRAM at 0.
The driver then uses the VBIOS layout (VRAM at 0xf400000000) from the
start, and later posts keep it. After the reset, FB_BASE is not 0, so
a module reload does not reset the ASIC again.
The test is the same one that commit c54e4d105077 ("drm/amdgpu: make
Mac FB workaround generic") uses: an Apple subsystem vendor and VRAM at
0. The VI quirk for the MacBookPro14,3 resets at load for the same
reason:
commit b6b1d9721851 ("drm/amdgpu: reset VI ASIC on MacBookPro14,3")
Other Apple SI boards get the same reset if FB_BASE reads 0 at load.
Tested on a MacBookPro11,5 with 7.2.5 and this patch: the panel comes
up at boot, and 4 of 4 deep S3 cycles resume. Without the patch, S3
resume fails every time. The GPU reset path is not tested.
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/5978
Assisted-by: Claude:claude-opus-5-5
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Maciej Kucharek <qchcio@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
amdgpu_device_supports_boco() returns true for an AMD_IS_PX device on a
system with a hybrid ATPX method even when the device has no ACPI power
resource (_PR3). On an APU mini PC with a discrete GPU attached over
OCuLink, the iGPU's ATPX method reports hybrid graphics, the dGPU is
flagged AMD_IS_PX, and runtime PM in auto mode picks BOCO:
amdgpu: ATPX Hybrid Graphics
amdgpu 0000:c6:00.0: Using BOCO for runtime pm
In BOCO mode the driver leaves powering the device off to the PCI core,
which can only do it through _PR3 on the upstream bridge. No device on
this dGPU's path has _PR3, so when it runtime suspends the card stays
powered, with its fans at about 700 rpm.
Require has_pr3 for BOCO, as the function's description ("dGPU with ACPI
power resources") says. The same card then picks BACO, which powers it
down:
amdgpu 0000:c6:00.0: Using BACO for runtime pm
This only changes systems with a hybrid ATPX method and no _PR3 on the
dGPU's upstream bridge, where BOCO cannot cut the power today. Tested on
one such system only, an RX 9070 XT (Navi 48) over OCuLink with a Ryzen
AI 9 HX 470, with the change backported to 7.2.9: the stock module logs
"Using BOCO", the patched one "Using BACO"; BACO runtime suspend powers
the card off and it resumes cleanly. Not tested on a hybrid laptop or a
Thunderbolt eGPU.
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/5980
Assisted-by: Claude:claude-opus-5-5
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Luigi Lauro <luigi.lauro@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
gfx_v7_0_sw_fini() and gfx_v8_0_sw_fini() already call
amdgpu_gfx_rlc_fini(), which releases the RLC objects used by these
IP blocks.
Remove the duplicated explicit frees of clear_state_obj and
cp_table_obj.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Willian Oliveira <williandossantosdeoliveira287@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Since commit 541c8f2468b9 ("dma-buf: detach fence ops on signal v3"),
I'm seeing the BUG_ON() triggering in drm_crtc's fence_to_crtc() via
drm_crtc_fence_get_driver_name() regularly:
Call trace:
panic+0x58/0x5c
die+0x160/0x178
bug_brk_handler+0x70/0xa4
call_el1_break_hook+0x3c/0x1a0
do_el1_brk64+0x24/0x74
el1_brk64+0x34/0x54
el1h_64_sync_handler+0x80/0xfc
el1h_64_sync+0x84/0x88
drm_crtc_fence_get_driver_name+0x60/0x68 (P)
sync_file_get_name+0x184/0x45c
sync_file_ioctl+0x404/0xf70
__arm64_sys_ioctl+0x124/0x1dc
This looks to be caused by a code flow similar to the following:
+++ snip +++
thread A thread B
ioctl(SYNC_IOC_FILE_INFO)
sync_file_ioctl()
sync_file_get_name()
dma_fence_signal_timestamp_locked() dma_fence_driver_name()
ops = rcu_dereference(fence->ops)
if (!dma_fence_test_signaled_flag())
ops->get_driver_name(fence) i.e.
drm_crtc_fence_get_driver_name()
test_and_set_bit(SIGNALED)
RCU_INIT_POINTER(fence->ops, NULL)
drm_crtc_fence_get_driver_name()
BUG_ON(rcu_access_pointer(fence->ops)
!= &drm_crtc_fence_ops)
+++ snap +++
In other words, a fence's ops pointer can now change to NULL on signal,
which wasn't the case before the culprit commit and hence the BUG_ON()
triggers.
Simply drop the BUG_ON() as it's usage of fence ops is invalid now, and
because using BUG_ON() and friends to take down the system is an
unacceptable way to handle a failure.
Note that the adjacent drm_crtc_fence_get_timeline_name() has the same
problem and is fixed by this patch as well.
Fixes: 541c8f2468b9 ("dma-buf: detach fence ops on signal v3")
Cc: stable@vger.kernel.org
Signed-off-by: André Draszik <andre.draszik@linaro.org>
Reviewed-by: Philipp Stanner <phasta@kernel.org>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
Link: https://lore.kernel.org/r/20260721-linux-drm_crtc_fix2-v3-2-afa8c71506e6@linaro.org
|
|
In [1], sashiko reported the following issue:
=== snip ===
Looking at how these fences are managed, drm_crtc_create_fence()
creates a dma_fence without taking a reference to the drm_device or
drm_crtc. Because the sync_file framework exposes this fence to
userspace, the fence can outlive the CRTC.
The dma_fence contract requires that data accessed by dma_fence_ops
(like get_driver_name) must remain valid for an RCU grace period after
the fence is signaled. However, drm_crtc_cleanup() and the subsequent
freeing of the device do not wait for an RCU grace period via
synchronize_rcu().
If userspace calls ioctl(SYNC_IOC_FILE_INFO) concurrently with a device
hot-unplug:
CPU1 (Userspace)
sync_file_get_name()
ops = rcu_dereference(fence->ops);
if (!dma_fence_test_signaled_flag())
// Preempted or delayed here
CPU2 (Driver Teardown)
Signals the fence (setting fence->ops = NULL)
Destroys and frees the CRTC without waiting for an RCU grace period
CPU1 (Resumes)
ops->get_driver_name(fence) -> drm_crtc_fence_get_driver_name()
crtc = fence_to_crtc(fence); // Casts to the freed CRTC
return crtc->dev->driver->name; // Use-after-free
...
Does the CRTC or DRM device need to be kept alive for the RCU grace
period, or should the fence hold a proper reference to prevent the
use-after-free when get_driver_name() and get_timeline_name() access
the freed CRTC structure?
=== snap ===
I believe this to be a correct observation and this patch implements
the suggestion of waiting for an RCU grace period before proceeding
with destruction of the drm_crtc, so that get_driver_name() and
get_timeline_name() can still work.
Link: https://sashiko.dev/#/patchset/20260618-linux-drm_crtc_fix2-v1-1-c03e77b36f34@linaro.org?part=1
Fixes: 6d6003c4b613 ("drm/fence: add fence timeline to drm_crtc")
Cc: stable@vger.kernel.org
Signed-off-by: André Draszik <andre.draszik@linaro.org>
Reviewed-by: Philipp Stanner <phasta@kernel.org>
Reviewed-by: Christian König <christian.koenig@amd.com>
Link: https://lore.kernel.org/r/20260721-linux-drm_crtc_fix2-v3-1-afa8c71506e6@linaro.org
Signed-off-by: Christian König <christian.koenig@amd.com>
|
|
'hyper-v', 'samsung/exynos', 'riscv', 'broadcom', 'intel/vt-d', 'amd/amd-vi' and 'core' into next
|
|
Update our preferred vmscan batch size for the non-purgeable shrinker
on count passes that allow backup (__GFP_FS), to avoid invoking
scan_objects() for requests too small to free even a single
average-sized GEM object. Our rough estimate for an effective batch
is twice the average number of pages per populated ttm_tt across
the full shrinkable and purgeable population. The factor of two
provides headroom so that most scan invocations can free at least one
GEM object despite variability in object sizes.
The batch value is updated as an exponential moving average,
(old_batch + avg) / 2, to smooth out sudden changes in the object
population. It is floored at 128 pages, the kernel default
SHRINK_BATCH, to ensure the shrinker remains responsive when there
are very few objects.
The populated_tts counter introduced in an earlier commit provides the
object count needed for the average. We inherit the same justification
as the analogous mechanism in i915: shrinking a GEM object has
non-trivial per-object overhead, so firing the shrinker for requests
smaller than a single object is wasteful.
This is only applied to the non-purgeable shrinker: purgeable objects
are reclaimed without writeback or GPU idling, so they're cheap enough
that the core default batch size is fine for them.
v3:
- Original patch reworked on top of shrinker split (Matt Brost)
Assisted-by: LLM
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patch.msgid.link/20261019095655.3501-5-thomas.hellstrom@linux.intel.com
|
|
Purgeable objects are reclaimed by simply discarding their pages, with
no writeback required. They are therefore much cheaper to shrink than
regular shrinkable (non-purgeable) objects, whose reclaim may need to
wait for the GPU or write dirty compressed contents back to a backup
store, and whose contents need to be read back on next use.
Split the single xe_shrinker into two independent struct shrinker
instances registered against the shrinker core, sharing the same
underlying accounting (shrinkable_pages, purgeable_pages,
populated_tts) and locking:
- A purgeable shrinker, whose count_objects() reports only
purgeable_pages, and whose scan_objects() only purges objects.
- A non-purgeable (shrinkable) shrinker, whose count_objects()
reports the shrinkable page count (capped by backup availability)
and whose scan_objects() shrinks non-purgeable objects, and also
purges any purgeable objects it encounters, waking the device via
runtime PM as needed.
Express the cost difference to the shrinker core through the seeks
value: the purgeable shrinker keeps DEFAULT_SEEKS, while the
non-purgeable shrinker uses a higher value, 8 by default. The core
scales each shrinker's scan target inversely with seeks, so purgeable
objects receive proportionally more reclaim pressure than non-purgeable
ones, without one shrinker's behaviour depending on the other's state.
To allow tuning, the default non-purgeable seeks value is set by
CONFIG_DRM_XE_SHRINKER_NON_PURGEABLE_SEEKS, and can be changed at
runtime through the per-device shrinker_non_purgeable_seeks sysfs
attribute. Valid values are 1 to 64. Zero is rejected, since the
shrinker core treats it specially.
The standalone purge walk relies on the LRU walk skipping
non-purgeable objects, for which xe_bo_shrink() returns -EBUSY,
rather than aborting.
v3:
- Patch introduced. (Matt Brost)
v4:
- The purge walk aborting at the first non-purgeable object is now
fixed by a separate, preceding patch. (Sashiko)
v5:
- Make the non-purgeable seeks value tunable through Kconfig and
sysfs. (Matt Brost)
Assisted-by: LLM
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patch.msgid.link/20261019095655.3501-4-thomas.hellstrom@linux.intel.com
|
|
Add a populated_tts counter to struct xe_shrinker to track how many
ttm_tts are currently populated and on the LRU (i.e., shrinkable or
purgeable). This mirrors the existing per-pages accounting but counts
objects rather than pages.
The counter is incremented in xe_ttm_tt_account_add() and decremented
in xe_ttm_tt_account_subtract(), which are already called at the exact
points where pages enter and leave the shrinker's jurisdiction (populate,
unpopulate, pin, and unpin). Purgeable state transfers, which move pages
between the shrinkable and purgeable buckets without changing the total
object count, pass tts=0.
Extend xe_shrinker_mod_pages() with a tts delta parameter so that page
and object accounting can be updated atomically under the same lock.
Assert that populated_tts reaches zero at device teardown, alongside
the existing assertions for shrinkable_pages and purgeable_pages.
No functional change intended; the new field is unused until a follow-up
commit wires it into shrinker batch sizing.
Assisted-by: LLM
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patch.msgid.link/20261019095655.3501-3-thomas.hellstrom@linux.intel.com
|
|
xe_bo_shrink() returns -EBUSY for bos that can't currently be shrunk,
for example imported dma-bufs, bos whose vm is currently validating,
bos that are still busy after the wait timeout, or bos whose backup
fails. The shrinker LRU walk treats any negative return value as
fatal and aborts, which also skips the remaining shrinker passes.
As a result, a single such bo, like an imported dma-buf on the
XE_PL_TT LRU, prevents reclaim of all bos behind it on the LRU.
Skip bos for which xe_bo_shrink() returns -EBUSY and continue the
walk, like the TTM LRU walk does.
v4:
- Patch introduced.
Fixes: 00c8efc3180f ("drm/xe: Add a shrinker for xe bos")
Cc: Christian König <christian.koenig@amd.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: intel-xe@lists.freedesktop.org
Cc: <stable@vger.kernel.org> # v6.15+
Assisted-by: LLM
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patch.msgid.link/20261019095655.3501-2-thomas.hellstrom@linux.intel.com
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs
Pull file table updates from Christian Brauner:
"This annotates struct fdtable's fd array with __counted_by_ptr so
KASAN and the fortified functions can bounds check it against max_fds
and adds a KUnit suite for fdtable. A follow-up uses __struct_size()
in the test since sparse doesn't know __builtin_dynamic_object_size().
FD_PREPARE() is simplified. It was built as an ACQUIRE-style guard on
infrastructure that was never needed. The ACQUIRE machinery and
CLASS_INIT() go away, the variable is declared with __cleanup()
directly, struct fd_prepare loses its err field since the fd either
holds the descriptor or the error, and callers get a const pointer to
the guard behind a UNIQUE_ID() name so they can't shadow it. Code
generation is identical"
* tag 'vfs-7.4-rc1.file' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs:
file: make struct fd_prepare const and kill its err field
cleanup: remove CLASS_INIT()
file: declare the FD_PREPARE() variable with __cleanup() directly
file: simplify FD_PREPARE()
vfs: use __struct_size() in the fdtable KUnit test
vfs: Add KUnit tests for fdtable
vfs: Annotate struct fdtable's fd field with __counted_by_ptr
|
|
Convert any errors that can cause the CT to be declared as dead to
use the xe_log_err() helper. Errors that are escalated to the callers
are left for the caller to report with SIGID if needed.
While at it, update some of the error messages to make what went wrong
clearer.
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
Assisted-by: Claude:claude-opus-5
Reviewed-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com>
Link: https://patch.msgid.link/20261016204354.364846-16-umesh.nerlige.ramappa@intel.com
|
|
Convert errors during critical GuC flows (init, load, reset, suspend)
to use the xe_log_err() helper.
While at it, simplify the error log for the GuC load failure to use the
cached frequency values instead of fetching them again.
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Link: https://patch.msgid.link/20261016204354.364846-15-umesh.nerlige.ramappa@intel.com
|
|
Convert the uC DMA failure error to use the xe_log_err() helper.
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Link: https://patch.msgid.link/20261016204354.364846-14-umesh.nerlige.ramappa@intel.com
|
|
Instead of always returning -EPROTO for most errors, use different error
codes based on the error type. -EPROTO is retained for the cases that
are genuine protocol violations by the GuC. The remaining cases now
report what actually went wrong.
A CTB that has been flagged broken reports -ECONNABORTED rather than
-EPERM. These errors are not contained within the driver: they reach
userspace verbatim through the gt freq sysfs knobs (min_freq_store() ->
xe_guc_pc_set_min_freq() -> xe_guc_ct_send()) and through the VFIO
SR-IOV migration callbacks (xe_sriov_vfio_suspend_device() ->
xe_sriov_pf_control_pause_vf() -> xe_guc_ct_send_block()). -EPERM reads
as a privilege failure, so a user who hits a broken CT is told
"Operation not permitted" and retries as root to no effect. Worse,
xe_sriov_vfio.c already returns -EPERM for its own "not a PF" check,
so the two are indistinguishable to migration tooling.
-ECONNABORTED ("Software caused connection abort") says what actually
happened: the driver aborted the channel after detecting corruption.
Note that -ECONNABORTED must stay distinct from -EPIPE. -EPIPE means
corruption was detected now and transitions the CTB to broken, which
g2h_err_is_fatal() classifies as fatal; -ECONNABORTED means the CTB was
already broken and is benign. Merging them would make receive_g2h()
re-declare the CT dead and re-kick a reset on every dequeue iteration.
receive_g2h() used to escalate to CT_DEAD + kick_reset() by matching the
two error codes that dequeue_one_g2h() could return on a fatal error.
Invert the check to simplify reset handling.
Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
Assisted-by: Claude:claude-opus-5
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Link: https://patch.msgid.link/20261016204354.364846-13-umesh.nerlige.ramappa@intel.com
|
|
Define ct_dead_capture for non-debug as well to simplify future
refactor. Rename it to process_ct_dead since non-debug mode does not
capture anything.
Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Link: https://patch.msgid.link/20261016204354.364846-12-umesh.nerlige.ramappa@intel.com
|
|
guc_crash_process_msg() handles both crash and exception notifications
from GuC, but ends up rechecking the type of notification. It also has
an else case that is not reachable.
Since notification type is already known by the caller, remove
guc_crash_process_msg() and handle the CRASH and EXCEPTION G2H
separately, so the duplicate check is avaoided.
Suggested-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Link: https://patch.msgid.link/20261016204354.364846-11-umesh.nerlige.ramappa@intel.com
|
|
Instead of always returning -EPROTO no matter what goes wrong, use
different error codes based on the error type.
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Link: https://patch.msgid.link/20261016204354.364846-10-umesh.nerlige.ramappa@intel.com
|
|
The compatibility number for the published GSC number is 1.0. The binary
is correctly named nvl_gsc_1.bin (matching the major compatibility
version number), but the driver is instead looking for compatibility 0.0
(which maps to nvl_gsc_0.bin), leading to the binary not being found.
The driver supports running without GSC so this is not fatal, but all
content protection features will not work without the GSC FW.
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Fixes: 8a90f0d1098f ("drm/xe/gsc: Define GSC for NVL-S")
Cc: Alan Previn <alan.previn.teres.alexis@intel.com>
Cc: Julia Filipchuk <julia.filipchuk@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Alan Previn <alan.previn.teres.alexis@intel.com>
Link: https://patch.msgid.link/20261015204548.147348-1-daniele.ceraolospurio@intel.com
|
|
Setting the panic screen through sysfs with echo fails with EINVAL,
because the value ends in a newline. Ignore it when matching.
Fixes: e85e9ccf3f84 ("drm/panic: Report invalid or unsupported panic modes")
Signed-off-by: Devin Wittmayer <lucid_duck@justthetip.ca>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
Link: https://patch.msgid.link/20261016052722.60051-2-lucid_duck@justthetip.ca
Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com>
|
|
The kmsg panic screen reads the log back one chunk at a time. A record
that does not fit in a chunk comes back empty without moving on, so the
screen asks for it again forever and the panic never finishes. Every
oops logs the list of loaded modules, and on my machine that list does
not fit.
Read into a buffer the size printk formats one record into, and stop if
a read still comes back empty.
Fixes: 54034bebb22f ("drm/panic: Add a kmsg panic screen")
Cc: stable@vger.kernel.org
Signed-off-by: Devin Wittmayer <lucid_duck@justthetip.ca>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://patch.msgid.link/20261016052722.60051-1-lucid_duck@justthetip.ca
Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com>
|
|
When kmsg_buf completes drawing the screen and yoffset is less than 0,
kmsg_dump_get_buffer continues to obtain the buffer. This potential loop
may cause panic_flush not to be executed immediately or even not to be
executed at all, resulting in a garbled screen display instead of normal
logs
So, the loop should be exited immediately after drawing kmsg_buf
Signed-off-by: luyuantao <luyuantao@kylinos.cn>
Acked-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://patch.msgid.link/20260126100732.365-1-luyuantao01@163.com
Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com>
|
|
These callbacks are never meant to modify their configfs_attribute
structure. Enforce this in the type system.
As there are only two implementers of these callbacks, adapt them right
away, avoiding a phased transition.
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Reviewed-by: Breno Leitao <leitao@debian.org>
Acked-by: Andreas Hindborg <a.hindborg@kernel.org>
Link: https://patch.msgid.link/20260716-configfs-const-base-v1-2-c545a4053cb5@weissschuh.net
Signed-off-by: Breno Leitao <leitao@debian.org>
|
|
The adp connector implementation uses the deprecated
drm_atomic_helper_connector_reset() as its reset hook.
Switch to drm_atomic_helper_connector_create_state() instead.
Acked-by: Aditya Garg <aditya.garg@linux.dev>
Link: https://lore.kernel.org/r/20261014-drm-no-more-connector-reset-v1-2-586c9c026823@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
|
|
The malidp writeback connector reset implementation creates a custom
state subclass, but only initializes a pristine state without resetting
any hardware. This is equivalent to what atomic_create_state expects.
Convert to it.
Reviewed-by: Liviu Dudau <liviu.dudau@arm.com>
Link: https://lore.kernel.org/r/20261014-drm-no-more-connector-reset-v1-67-586c9c026823@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
|
|
The vc4 connector implementation uses the deprecated
drm_atomic_helper_connector_reset() as its reset hook.
Switch to drm_atomic_helper_connector_create_state() instead.
Reviewed-by: Maíra Canal <mcanal@igalia.com>
Link: https://lore.kernel.org/r/20261014-drm-no-more-connector-reset-v1-51-586c9c026823@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
|
|
The sysfb connector implementation uses the deprecated
drm_atomic_helper_connector_reset() as its reset hook.
Switch to drm_atomic_helper_connector_create_state() instead.
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://lore.kernel.org/r/20261014-drm-no-more-connector-reset-v1-39-586c9c026823@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
|
|
The solomon: ssd130x connector implementation uses the deprecated
drm_atomic_helper_connector_reset() as its reset hook.
Switch to drm_atomic_helper_connector_create_state() instead.
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://lore.kernel.org/r/20261014-drm-no-more-connector-reset-v1-35-586c9c026823@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
|
|
The imx: ipuv3 connector implementation uses the deprecated
drm_atomic_helper_connector_reset() as its reset hook.
Switch to drm_atomic_helper_connector_create_state() instead.
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://lore.kernel.org/r/20261014-drm-no-more-connector-reset-v1-25-586c9c026823@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
|
|
The hyperv connector implementation uses the deprecated
drm_atomic_helper_connector_reset() as its reset hook.
Switch to drm_atomic_helper_connector_create_state() instead.
Reviewed-by: Saurabh Sengar <ssengar@linux.microsoft.com>
Tested-by: Saurabh Sengar <ssengar@linux.microsoft.com>
Link: https://lore.kernel.org/r/20261014-drm-no-more-connector-reset-v1-24-586c9c026823@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
|
|
The bridge: megachips connector implementation uses the deprecated
drm_atomic_helper_connector_reset() as its reset hook.
Switch to drm_atomic_helper_connector_create_state() instead.
Reviewed-by: Ian Ray <ian.ray@gehealthcare.com>
Link: https://lore.kernel.org/r/20261014-drm-no-more-connector-reset-v1-12-586c9c026823@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
|
|
The bridge: lontium-lt8912b connector implementation uses the deprecated
drm_atomic_helper_connector_reset() as its reset hook.
Switch to drm_atomic_helper_connector_create_state() instead.
Acked-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Link: https://lore.kernel.org/r/20261014-drm-no-more-connector-reset-v1-11-586c9c026823@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
|
|
The arm: komeda connector implementation uses the deprecated
drm_atomic_helper_connector_reset() as its reset hook.
Switch to drm_atomic_helper_connector_create_state() instead.
Reviewed-by: Liviu Dudau <liviu.dudau@arm.com>
Link: https://lore.kernel.org/r/20261014-drm-no-more-connector-reset-v1-5-586c9c026823@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
|
|
Right now, there's a theoretical window during which the GPU can populate
the cache with data from a VM that's about to be evicted through the
UPDATE(UNMAPPED) command.
In practice this won't happen (hence the absence of Fixes tag) because
when panthor_mmu_as_disable() is called, the VM is guaranteed to be idle
(no active CSG pointing to this VM), but as we say, better safe than
sorry.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
Link: https://patch.msgid.link/20260924-panthor-mmu-fixes-v1-3-e25f9b106466@collabora.com
|
|
We're trying to be smart by skipping the UPDATE(UNMAPPED) step, but
it remains to be proven it adds any noticeable overhead. Moreover, it's
breaking the assumption that, once the VM is unbound, no access can
happen on it.
For instance, say the panthor_mmu_as_enable() call in panthor_vm_active()
fails after we've called panthor_vm_release_as_locked(), we're now in a
state where the HW still points to the old page table, but SW slot points
to the new VM, which is not truly HW-bound.
If, after the as_slots lock is released, the evicted VM itself is
released, the HW might have access to memory that has been returned
to the system until the reset we scheduled (because of the faulty
AS_COMMAND) is effective.
Let's make this bullet-proof by doing a full bound -> unbound -> bound
cycle on AS slot recycling.
Fixes: 32e593d74c39 ("drm/panthor: Make sure caches are flushed/invalidated when an AS is recycled")
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Liviu Dudau <liviu.dudau@arm.com>
Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
Link: https://patch.msgid.link/20260924-panthor-mmu-fixes-v1-2-e25f9b106466@collabora.com
|
|
Don't invalidate the OTHER caches (AKA L1 read-only caches) since
this seems to trip out the flush-elimination logic on v13, and it's not
needed in practice (can't leak other context data because of TLB
invalidation or corrupt physical pages returned to the system because
it's a RO cache).
It's also worth noting that the downstream driver has been avoid
OTHER caches invalidation from the start, and that we were doing
the same until atomic page table update was introduced.
Fixes: 6e2d3b3e8589 ("drm/panthor: Add support for atomic page table updates")
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Liviu Dudau <liviu.dudau@arm.com>
[Update comment as suggested by sashiko]
Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
Link: https://patch.msgid.link/20260924-panthor-mmu-fixes-v1-1-e25f9b106466@collabora.com
|
|
drm_connector_attach_encoder() replaced an earlier call to
drm_simple_display_pipe_init() during review, but the error message
logged on failure was not updated to match and still refers to the
old call.
Fixes: 0670c2f56e45 ("drm/tiny: add driver for Apple Touch Bars in x86 Macs")
Signed-off-by: Adam Azuddin <azuddinadam@gmail.com>
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Link: https://patch.msgid.link/20260926-fix-err-msg-appletbdrm-v1-1-bb578a7dbdda@gmail.com
|
|
Switch driver over to the new drmm_connector_hdmi_init() signature and
advertise HDMI 1.2 support. The vendor, product, supported_formats and
max_bpc values previously passed as arguments are now provided through
struct drm_connector_hdmi_funcs, together with the new
supported_hdmi_ver field.
The HDMI connector helpers infer the 165 MHz TMDS character rate ceiling
from supported_hdmi_ver and reject modes exceeding it before invoking
the driver's .tmds_char_rate_valid() hook. This makes the explicit mode
clock check in sun4i_hdmi_connector_clock_valid() redundant, so drop it.
No functional change intended.
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Tested-by: Igor Paunovic <royalnet026@gmail.com> # RK3588 Orange Pi 5 Plus, dual HDMI
Tested-by: Robin Räber <robin.raebi@gmail.com>
Link: https://patch.msgid.link/20261001-bridge-advert-hdmi-caps-v1-8-f8806570e243@collabora.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
|
|
Bridges using DRM_BRIDGE_OP_HDMI are now expected to also provide a
supported HDMI version. This is not yet enforced, but will become
mandatory once the migration to the new caps-based HDMI connector
initialization API is completed.
The RK3066 HDMI TX supports HDMI 1.4a, as described in commit
f84d3d37b7fb ("drm: rockchip: introduce rk3066 hdmi"). However, the
driver does not currently enforce a maximum TMDS character rate, it only
filters non-CEA modes and excludes VIC 1 (640x480) via the .mode_valid
callback.
Advertise HDMI 1.4 support for now so that modes exceeding the 340 MHz
TMDS limit are rejected by the core.
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Tested-by: Igor Paunovic <royalnet026@gmail.com> # RK3588 Orange Pi 5 Plus, dual HDMI
Tested-by: Robin Räber <robin.raebi@gmail.com>
Link: https://patch.msgid.link/20261001-bridge-advert-hdmi-caps-v1-7-f8806570e243@collabora.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
|
|
Bridges using DRM_BRIDGE_OP_HDMI are expected to provide the supported
HDMI version. This is not enforced yet, but will become mandatory once
the migration to the caps-based HDMI connector initialization API is
complete.
As LT9611 supposedly cannot drive a TMDS character rate exceeding 297
MHz, advertise HDMI 1.4 as the supported version. HDMI 1.4 allows up to
340 MHz, so set the bridge's max_tmds_char_rate to ensure the connector
limit derived from supported_hdmi_ver remains within the hardware
capabilities.
drm_bridge_connector_atomic_check() calls
drm_atomic_helper_connector_hdmi_check(), which rejects modes whose
computed TMDS character rate exceeds the connector's max_tmds_char_rate
before invoking the driver's .tmds_char_rate_valid hook. Since
max_tmds_char_rate now carries the existing effective limit,
lt9611_hdmi_tmds_char_rate_valid() is redundant. Drop it.
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Tested-by: Igor Paunovic <royalnet026@gmail.com> # RK3588 Orange Pi 5 Plus, dual HDMI
Tested-by: Robin Räber <robin.raebi@gmail.com>
Tested-by: Diederik de Haas <diederik@cknow-tech.com> # NanoPC-T6 LTS, Rock 5B
Link: https://patch.msgid.link/20261001-bridge-advert-hdmi-caps-v1-6-f8806570e243@collabora.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
|
|
Bridges using DRM_BRIDGE_OP_HDMI are now expected to also provide a
supported HDMI version. This is not yet enforced, but will become
mandatory once the migration to the new caps-based HDMI connector
initialization API is completed.
Since none of the chip variants handled by the driver can drive a TMDS
character rate exceeding 148.5 MHz, advertise HDMI 1.2 as the supported
version. HDMI 1.2 allows up to 165 MHz, so set the bridge's
max_tmds_char_rate to ensure the connector limit derived from
supported_hdmi_ver remains within the hardware capabilities.
drm_bridge_connector_atomic_check() runs
drm_atomic_helper_connector_hdmi_check(), which rejects modes whose
computed TMDS character rate exceeds the connector limit before invoking
the driver's .tmds_char_rate_valid() hook, making the max_rate check in
it66121_bridge_hdmi_tmds_char_rate_valid() redundant. Drop it.
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Tested-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Tested-by: Igor Paunovic <royalnet026@gmail.com> # RK3588 Orange Pi 5 Plus, dual HDMI
Tested-by: Robin Räber <robin.raebi@gmail.com>
Tested-by: Diederik de Haas <diederik@cknow-tech.com> # NanoPC-T6 LTS, Rock 5B
Link: https://patch.msgid.link/20261001-bridge-advert-hdmi-caps-v1-5-f8806570e243@collabora.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
|
|
Bridges using DRM_BRIDGE_OP_HDMI are expected to provide the supported
HDMI version. This is not enforced yet, but will become mandatory once
the migration to the caps-based HDMI connector initialization API is
complete.
Advertise HDMI 1.3 support for IT6263, covering the 225 MHz TMDS
character rate currently documented by the driver, which is within the
HDMI 1.3 limit of 340 MHz. Additionally, keep the stricter 150 MHz
effective mode limit by setting max_tmds_char_rate from
MAX_PIXEL_CLOCK_KHZ.
The existing .hdmi_tmds_char_rate_valid() hook checks both the pixel
clock and TMDS character rate. Since the bridge only supports 8 bpc
RGB444, these are equivalent for supported modes, making the 225 MHz
TMDS rate check unreachable once the 150 MHz pixel-clock limit is
applied.
drm_bridge_connector_atomic_check() invokes
drm_atomic_helper_connector_hdmi_check(), which rejects modes whose
computed TMDS character rate exceeds the connector's max_tmds_char_rate
before invoking the driver's .tmds_char_rate_valid hook. Since
max_tmds_char_rate now carries the existing effective limit,
it6263_hdmi_tmds_char_rate_valid() is redundant. Drop it.
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Tested-by: Igor Paunovic <royalnet026@gmail.com> # RK3588 Orange Pi 5 Plus, dual HDMI
Tested-by: Robin Räber <robin.raebi@gmail.com>
Tested-by: Diederik de Haas <diederik@cknow-tech.com> # NanoPC-T6 LTS, Rock 5B
Link: https://patch.msgid.link/20261001-bridge-advert-hdmi-caps-v1-4-f8806570e243@collabora.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
|
|
Bridges using DRM_BRIDGE_OP_HDMI expect connectors to be created through
drm_bridge_connector_init(), thereby relying on the bridge connector's
.mode_valid hook to invoke drm_hdmi_connector_mode_valid().
The generic helper computes the mode's TMDS character rate and forwards
it to the bridge's .hdmi_tmds_char_rate_valid callback through the
connector HDMI funcs. This covers exactly what
it6263_bridge_mode_valid() does for 8 bpc RGB444, but due to being
output-format aware, it also handles the validation more thoroughly.
Both the connector and bridge .mode_valid hooks are invoked during
mode validation through drm_mode_validate_pipeline(), so the custom
bridge hook is redundant. Drop it.
While at it, remove the now-unused drm_hdmi_helper.h include.
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Tested-by: Igor Paunovic <royalnet026@gmail.com> # RK3588 Orange Pi 5 Plus, dual HDMI
Tested-by: Robin Räber <robin.raebi@gmail.com>
Tested-by: Diederik de Haas <diederik@cknow-tech.com> # NanoPC-T6 LTS, Rock 5B
Link: https://patch.msgid.link/20261001-bridge-advert-hdmi-caps-v1-3-f8806570e243@collabora.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
|
