| Age | Commit message (Collapse) | Author |
|---|
|
During VM teardown, the VM's runtime PM reference is dropped
asynchronously, allowing the device to autosuspend while stale page
faults belonging to the now-dead VM are still queued. When the
page-fault worker later tries to ack one of these, it calls into
guc_ct_send_locked() on an already-suspended device, tripping:
Assertion `!xe_pm_runtime_suspended(xe)` failed!
WARNING at xe_device.c:1267 xe_device_assert_mem_access+0x11c/0x140 [xe]
A live VM/exec queue always holds a PM reference while it has
outstanding work, so if the device is suspended at ack time, the
owning context is already gone and the fault is stale.
Take a runtime PM reference across the entire pagefault
queue worker to safely deliver acks for torn-down VMs.
v3:
- Move PM ref to the generic xe_pagefault_queue_work using
guard(xe_pm_runtime)(xe) instead of tracking it in the GuC
backend(Matt Brost).
v2:
- Hold PM ref across the entire batch (begin/end) instead of per-ack.
This prevents the device from autosuspending mid-batch, which would
leave write_only acks written but the end flush skipped, and skip
counter++, desyncing the cadence check.(Himal)
- Add a comment explaining stale faults.(Himal)
Fixes: f289f7807119 ("drm/xe: Add xe_guc_pagefault layer")
Signed-off-by: Varun Gupta <varun.gupta@intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Tejas Upadhyay <tejas.upadhyay@intel.com>
Link: https://patch.msgid.link/20260907050011.497181-2-varun.gupta@intel.com
Signed-off-by: Tejas Upadhyay <tejas.upadhyay@intel.com>
|
|
Backmerging to get drm-misc-next up to v7.3-rc2. Requested for
commit 3a2c4d55e32a ("treewide: refresh kmalloc_obj() conversions").
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
|
|
Add self-tests for the PRAMIN aperture mechanism to verify correct
operation during GPU probe. The tests validate various alignment
requirements and corner cases.
The tests are default disabled and behind CONFIG_NOVA_CORE_SELFTESTS.
When enabled, tests run after GSP boot during probe.
Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
[ecourtney: convert the tests to window_at(), macros, and the new types]
[ecourtney: cfg-gate the tests and expect(dead_code), not a runtime no-op]
[ecourtney: run the self-tests on all architectures, drop the chipset arg]
[ecourtney: test within a usable FB region, skip when none is large enough]
[ecourtney: report failures without failing probe, start banner at dev_dbg]
[ecourtney: removed the mm-specific Kconfig option]
Signed-off-by: Eliot Courtney <ecourtney@nvidia.com>
Acked-by: Danilo Krummrich <dakr@kernel.org>
Link: https://patch.msgid.link/20260827-pramin-split-v3-10-24b24d7afc52@nvidia.com
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
|
|
The existing assert! and assert_eq! macros cause a panic. For self tests
in nova-core, it's inconvenient to cause a panic since these need to be
run on actual hardware. Instead, define similar macros that log an error
then return an Err.
Also add the NOVA_CORE_SELFTESTS Kconfig option that gates the driver
self-tests.
Signed-off-by: Eliot Courtney <ecourtney@nvidia.com>
Acked-by: Danilo Krummrich <dakr@kernel.org>
Link: https://patch.msgid.link/20260827-pramin-split-v3-9-24b24d7afc52@nvidia.com
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
|
|
Introduce GpuMm as the centralized GPU memory manager. At this point in
the series, GpuMm only owns the PRAMIN window for direct VRAM access;
the buddy allocator and TLB manager are added later when those backing
types become available.
This provides a clean ownership model where GpuMm provides accessor
methods for its components that can be used for memory management
operations, and lets follow-on patches (such as the PRAMIN aperture
self-tests) reference `pramin_mut()` cleanly.
Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
[ecourtney: squash the total VRAM end patch, drop its dev_info print]
[ecourtney: take the maximum FB limit before adding one, fail with EINVAL]
[ecourtney: rebase for the Bar0 lifetime and ownership changes, drop Arcs]
[ecourtney: source the chipset through gsp_resources]
[ecourtney: build the VRAM region in new(), pramin() becomes pramin_mut()]
[ecourtney: declare mm before gsp_resources, doc wording cleanups]
Signed-off-by: Eliot Courtney <ecourtney@nvidia.com>
Acked-by: Danilo Krummrich <dakr@kernel.org>
Link: https://patch.msgid.link/20260827-pramin-split-v3-8-24b24d7afc52@nvidia.com
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
|
|
PRAMIN apertures are a crucial mechanism for direct CPU read/write to
VRAM. Add a `Pramin` manager whose `window_at()` returns a typed MMIO
view of VRAM through the 1 MiB PRAMIN aperture in BAR0, validating the
view against the VRAM region and repositioning the window as needed for
the accessed address.
A view borrows `Pramin` mutably, so the window cannot move while
the view is in use, and it inserts an ordering point on Drop.
Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
[ecourtney: split the registers and HAL into the two preceding patches]
[ecourtney: rebase w.r.t. Bar0 lifetime changes and register projections]
[ecourtney: drop the window guard and mutex, use &mut self]
[ecourtney: position at init to avoid reads, reposition in window_offset]
[ecourtney: return typed MMIO views instead of read/write accessors]
[ecourtney: insert an ordering read when a view drops]
[ecourtney: declare the window location, drop the doc examples]
[ecourtney: add the copyright header, doc and naming cleanups]
[ecourtney: the pramin module is mm-internal]
Co-developed-by: Eliot Courtney <ecourtney@nvidia.com>
Signed-off-by: Eliot Courtney <ecourtney@nvidia.com>
Acked-by: Danilo Krummrich <dakr@kernel.org>
Link: https://patch.msgid.link/20260827-pramin-split-v3-6-24b24d7afc52@nvidia.com
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
|
|
Positioning the PRAMIN window requires writing an architecture-specific
register: `NV_PBUS_BAR0_WINDOW` on Turing, Ampere and Ada, and
`NV_XAL_EP_BAR0_WINDOW` with a different field width on Hopper and on
Blackwell.
A `MmHal` trait with one implementation per hardware family hides the
register choice from the rest of the mm code, matching the layout of
the driver's other HALs.
Signed-off-by: Eliot Courtney <ecourtney@nvidia.com>
Acked-by: Danilo Krummrich <dakr@kernel.org>
Link: https://patch.msgid.link/20260827-pramin-split-v3-4-24b24d7afc52@nvidia.com
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
|
|
PRAMIN apertures are a crucial mechanism for direct CPU read/write to
VRAM. Add the BAR0 window registers that position the PRAMIN aperture
on all supported GPU architectures: Turing, Ampere, Ada (via
`NV_PBUS_BAR0_WINDOW`), Hopper (via `gh100::NV_XAL_EP_BAR0_WINDOW`),
and Blackwell (via `gb100::NV_XAL_EP_BAR0_WINDOW`).
Hopper/Blackwell window-base registers are based on Eliot Courtney's
offlist reference patch.
Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
[ecourtney: split the registers out of the PRAMIN patch into mm/regs.rs]
[ecourtney: drop the register read path]
[ecourtney: reword the message for the split, narrow visibility to mm]
[ecourtney: plain base fields, as the bitfield cast+shift patch is dropped]
[ecourtney: rename the target to VidMem, fix derives, redo the target docs]
[ecourtney: annotate the register base types]
Signed-off-by: Eliot Courtney <ecourtney@nvidia.com>
Acked-by: Danilo Krummrich <dakr@kernel.org>
Link: https://patch.msgid.link/20260827-pramin-split-v3-3-24b24d7afc52@nvidia.com
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
|
|
Later patches align VRAM addresses down to the PRAMIN window. Implement
`Alignable` trait for `VramAddress` and plus add a `ZERO` constant.
Also print the address in hex under `{:?}`, so it reads well in debug
output.
Signed-off-by: Eliot Courtney <ecourtney@nvidia.com>
Acked-by: Danilo Krummrich <dakr@kernel.org>
Link: https://patch.msgid.link/20260827-pramin-split-v3-2-24b24d7afc52@nvidia.com
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
|
|
Add the `VramAddress` type representing a physical address in VRAM. Also
add an arithmetic helper, comparison, and operator overloads which are
required in later patches for address arithmetic.
Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
[ecourtney: create mm.rs here, squashing in the arithmetic patch]
[ecourtney: splice the two commit bodies]
[ecourtney: drop the Pfn fields, open-coding what bitfield! generated]
[ecourtney: drop align_down and the IntoVramOffset/IntoVramRange traits]
[ecourtney: make checked_add() const over a plain u64, derive the ordering]
[ecourtney: doc wording, header, import, and signature cleanups]
Signed-off-by: Eliot Courtney <ecourtney@nvidia.com>
Acked-by: Danilo Krummrich <dakr@kernel.org>
Link: https://patch.msgid.link/20260827-pramin-split-v3-1-24b24d7afc52@nvidia.com
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core into drm-rust-next
rust: io: support register projections and remove relative registers
Currently registers work for all untyped I/O regions, which is not ideal.
It allows registers defined for device A to work for another device B and
there is no safeguarding at all.
Change this by requiring a base type for registers. `register!` can still
define registers on untyped `Region`s, although users would need to do so
explicitly and supply a concrete type.
This change makes it possible to use projection for relative registers;
relative registers can be implemented by defining new types for the I/O
subregions and just define registers for these subregion types like normal
registers.
This actually results in more ergnomic code for users of relative registers
(currently only nova-core), because non-array registers can be written to
with
#[...]
struct Subregion(...);
register! {
base: MyBase;
SUBREGION: Subregion @ ...;
}
register! {
base: Subregion;
REG(u32) @ .. { .. }
}
let subregion = io_project!(bar, build: SUBREGION);
subregion.read(REG)
subregion.write_reg(reg)
instead of
struct SubregionType;
struct Subregion;
impl RegisterBase<SubregionType> for Subregion {
const BASE: usize = ...;
}
register! {
REG(u32) @ Subregion + .. { .. }
}
bar.read(REG::of::<Subregion>())
bar.write(WithBase::of::<Subregion>(), reg)
This also allows a lot more code sharing between I/O projection and
`register!` macro.
The expressiveness power of Rust declarative macros is becoming limiting,
so it is converted to a proc macro before new features being added to it.
This is a stable tag for other trees to merge.
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
Similar to the PFALCON and PFALCON2 conversion, the hshub0 relative access
can also be achieved cleanly with projection and a new base.
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Gary Guo <gary@garyguo.net>
Tested-by: Alexandre Courbot <acourbot@nvidia.com>
Link: https://patch.msgid.link/20260901-typed_register-v4-13-5552b1d59525@garyguo.net
[ Split nested import into kernel vertical style. - Danilo ]
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
Add fixed size region types `PFalconRegisters` and `PFalcon2Registers` and
update PFALCON and PFALCON2 registers to be fixed register on them and not
relative registers on `NovaRegisters`.
Update `Falcon` struct to store projected views when constructing and
access with `self.pfalcon` and `self.pfalcon2`.
Signed-off-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Tested-by: Alexandre Courbot <acourbot@nvidia.com>
Link: https://patch.msgid.link/20260901-typed_register-v4-12-5552b1d59525@garyguo.net
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
All registers use the same base type, which is `<IoMem as IO>::Target`.
Thus add the base parameter to `register!` invocation.
Signed-off-by: Gary Guo <gary@garyguo.net>
Tested-by: Alexandre Courbot <acourbot@nvidia.com>
Link: https://patch.msgid.link/20260901-typed_register-v4-8-5552b1d59525@garyguo.net
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
All registers use the same base type, which is `<Bar0 as IO>::Target`. Thus
add the base parameter to `register!` invocation.
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Gary Guo <gary@garyguo.net>
Tested-by: Alexandre Courbot <acourbot@nvidia.com>
Link: https://patch.msgid.link/20260901-typed_register-v4-7-5552b1d59525@garyguo.net
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux
Pull kmalloc_obj conversions from Kees Cook:
"Another run of the Coccinelle script for converting kmalloc()
family of allocations to kmalloc_obj() via the existing rules
in scripts/coccinelle/api/kmalloc_objs.cocci"
* tag 'kmalloc_obj-v7.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux:
treewide: refresh kmalloc_obj() conversions
drm/amd/display: Fix harmless type mismatch in allocation
|
|
The doc comment on the GSP message type names Cmdq as the type that
defines wait_for_msg. That method belongs to CmdqInner, so the link has
no target. Nothing catches the break, because rustdoc resolves a link
only in an item it documents, and the kernel's rustdoc run skips private
items.
Point the link at CmdqInner.
Assisted-by: LLM
Signed-off-by: John Hubbard <jhubbard@nvidia.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260905023800.1293631-1-jhubbard@nvidia.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
This is another run of the Coccinelle script for converting kmalloc()
family of allocations to kmalloc_obj() via the existing rules in
scripts/coccinelle/api/kmalloc_objs.cocci
This catches both the set of kmalloc() uses added since the first
kmalloc_obj() conversions in v7.0 and adds a large group missed in the
first pass due to Coccinelle not interacting well with the cleanup.h
scoped_...() family of macros[1]. I worked around this with spatch's
"--macro-file" argument to a file with all the scoped_...() macros mapped
to Coccinelle's YACFE_ITERATOR[2] as that was the closest viable control
flow indicator I could find.
Build tested allmodconfig on x86, arm64, arm, loongarch, mips, powerpc,
riscv, and s390 with no new warnings.
Link: https://lore.kernel.org/lkml/202609021314.8A9C0B8@keescook/ [1]
Link: https://github.com/coccinelle/coccinelle/blob/master/standard.h [2]
Signed-off-by: Kees Cook <kees+treewide@kernel.org>
|
|
While converting to kmalloc_obj() API, a type assignment mismatch was
found between the desired struct dcn42_resource_pool and the allocated
struct dcn401_resource_pool. Fix the type (it is harmless: the objects
have the same contents and size).
Signed-off-by: Kees Cook <kees@kernel.org>
---
Cc: Harry Wentland <harry.wentland@amd.com>
Cc: Leo Li <sunpeng.li@amd.com>
Cc: Rodrigo Siqueira <siqueira@igalia.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: "Christian König" <christian.koenig@amd.com>
Cc: David Airlie <airlied@gmail.com>
Cc: Simona Vetter <simona@ffwll.ch>
Cc: Dan Wheeler <daniel.wheeler@amd.com>
Cc: Roman Li <Roman.Li@amd.com>
Cc: Ovidiu Bunea <ovidiu.bunea@amd.com>
Cc: Charlene Liu <Charlene.Liu@amd.com>
Cc: Leo Chen <leo.chen@amd.com>
Cc: Ivan Lipski <ivan.lipski@amd.com>
Cc: Gaghik Khachatrian <gaghik.khachatrian@amd.com>
Cc: <amd-gfx@lists.freedesktop.org>
Cc: <dri-devel@lists.freedesktop.org>
|
|
Add a lifetime parameter to Coherent and CoherentBox that ties the DMA
allocation to the device's bound scope, ensuring it is freed before the
device is unbound.
DMA allocations carry device resources (e.g. IOMMU mappings) that must
not outlive the device's bound lifetime. Without a lifetime parameter,
there was no compile-time enforcement that a Coherent or CoherentBox is
dropped before the device is unbound.
Propagate the new lifetime parameter through all users.
Reviewed-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260830193824.471089-5-dakr@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
Add a lifetime parameter to CoherentHandle that ties the DMA allocation
to the device's bound scope, ensuring it is freed before the device is
unbound.
DMA allocations carry device resources (e.g. IOMMU mappings) that must
not outlive the device's bound lifetime. Without a lifetime parameter,
there was no compile-time enforcement that a CoherentHandle is dropped
before the device is unbound.
Reviewed-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260830193824.471089-3-dakr@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
https://gitlab.freedesktop.org/drm/xe/kernel into drm-fixes
A small fix on the error handling of an OA uapi and the
addition of a drm_info message to report FLAT_CSS base misalignment.
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patch.msgid.link/apnVOtDv4WAIoj_X@intel.com
|
|
https://gitlab.freedesktop.org/drm/amdgpu/kernel into drm-fixes
amd-drm-fixes-7.3-2026-09-03:
amdgpu:
- SR-IOV fix
- GFX8 fix
- MES queue reset fix
- GPUVM fixes
- DCN 6 warning fix
- DCN 3.5/3.6 fix
- DML fix
- Backlight fix
- Colorop fix
- DC get_estimated_bw() fix
- devcoredump fix
- Userq fixes
- APU PSP fix
- Cursor fix
amdkfd:
- MES queue eviction fix
- MQD debugfs fix
UAPI:
- Fix for drm_amdgpu_info_device with mixed 64 bit kernel and 32 bit userspace
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Alex Deucher <alexander.deucher@amd.com>
Link: https://patch.msgid.link/20260903174712.584320-1-alexander.deucher@amd.com
|
|
https://gitlab.freedesktop.org/drm/i915/kernel into drm-fixes
drm/i915 fixes for v7.3-rc2:
- Drop an accidentally duplicated panel fitter call in DP MST
- Fix DDI clock programming for Cx0 and LT PHY
- Fix PTL CDCLK handling at probe, causing a glitch
- Fix dg2_power_well_count() return type
- Fix a NULL pointer deref at forced probe
- Fix selective fetch disable
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Jani Nikula <jani.nikula@intel.com>
Link: https://patch.msgid.link/affe11af9d5eb9dc6f906441495cb843f9d4817c@intel.com
|
|
Add a fault-inject based debugfs interface for testing VRAM page
offlining. This replaces the previous standalone debugfs approach
with the standard kernel fault-inject infrastructure.
Two debugfs entries are created under the xe debugfs root for
CRI platforms:
- inject_mempage_offline/: Standard fault-inject knobs (probability,
times, interval, etc.) created by fault_create_debugfs_attr().
Without CONFIG_FAULT_INJECTION_DEBUG_FS, the stub returns
ERR_PTR(-ENODEV) and no knobs are created, making the trigger
effectively a no-op.
- inject_mempage_offline_trigger: Write a PFN value to inject a
specific page, or write "0" to auto-pick the last unallocated
VRAM page
The trigger accepts:
- "0" : auto-pick last unallocated page
- "0xPFN" : inject fault at a specific PFN address
Usage:
echo 100 > inject_mempage_offline/probability
echo 1 > inject_mempage_offline/times
echo 0 > inject_mempage_offline_trigger
probability: likelihood of should_fail() returning true (0-100)
times: number of times injection is allowed (-1 for unlimited)
v7:
- Use PAGE_SIZE
v6(Himal):
- Add warning to rebind driver post test run
v5(Sashiko):
- exclude SRIOV and remove dpa_base addition, already absolute dpa
v4(Himal):
- Use xe_fault_mempage_offline() instead of IS_ENABLED() +
direct should_fail(). CONFIG_FAULT_INJECTION_DEBUG_FS is now
an implicit requirement for the trigger to function.
v3(Himal):
- Use FAULT_ACTION
v2(sashiko):
- use cond_resched()
- validate input first and fix addr < 0 case
- validate vr, move block, found var as local to scope_guard
Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
Signed-off-by: Tejas Upadhyay <tejas.upadhyay@intel.com>
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patch.msgid.link/20260903161553.528932-32-tejas.upadhyay@intel.com
|
|
Extend DRM_XE_EXEC_QUEUE_GET_PROPERTY_BAN to return a bitmask indicating
the reason for the ban, rather than a simple boolean. This allows
userspace to distinguish between different ban causes:
- DRM_XE_EXEC_QUEUE_BAN_REASON_GPU_HANG (bit 0): exec queue was banned
due to a GPU hang or job timeout detected by the TDR.
- DRM_XE_EXEC_QUEUE_BAN_REASON_PAGE_OFFLINE (bit 1): exec queue was
banned because a VRAM page backing its resources was taken offline.
The ban_reason field is added to struct xe_exec_queue and set at the
point where the ban is triggered:
- In guc_exec_queue_timedout_job() for GPU hang.
- In xe_ttm_vram_purge_page() for memory page offline, before calling
xe_exec_queue_kill() or xe_vm_kill().
The reset_status op is updated to return u64 with the reason bitmask.
When a queue is banned but no explicit reason was recorded (e.g., from a
generic CAT error), it defaults to GPU_HANG for backward compatibility.
A value of 0 means the exec queue is not banned.
v5 (Sashiko/MattB):
- Take the write lock for the traversal to tag ban_reason
v4(Sashiko):
- Add ban reason for non-LR exec queues
- Add TODO for multiqueue
v3(Rodrigo):
- Add doc in xe_drm.h
v2(Sashiko):
- Use atomic_t for ban_reason to fix concurrent updates from TDR and
page-offline
- Guard GPU_HANG bit with !exec_queue_killed to avoid masking
page-offline reason
- Clear ban_reason on queue recovery (clear_exec_queue_banned path)
- Use atomic_read in guc_exec_queue_reset_status for lockless read
Assisted-by: Copilot:claude-opus-4.6
Acked-by: José Roberto de Souza <jose.souza@intel.com>
Acked-by: Michal Mrozek <michal.mrozek@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
Signed-off-by: Tejas Upadhyay <tejas.upadhyay@intel.com>
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patch.msgid.link/20260903161553.528932-31-tejas.upadhyay@intel.com
|
|
Add a debugfs file "vram_bad_pages" that shows offlined and queued
VRAM pages across all tiles. Each entry displays the page frame number,
GPU page size, and status flag (R=reserved, P=pending, F=failed).
example,
cat /sys/kernel/debug/dri/0/vram_bad_pages
max_pages: 10000
0x0000000000000000 : 0x0000000000001000 : R
0x0000000000001234 : 0x0000000000001000 : P
0x0000000000080000 : 0x0000000000001000 : R ← tile 1 addr
v3(Michal):
-add kernel doc
v2(Sashikoi/Michal/Himal):
-Remove block iteration, use offline and queue list only
-Move platform check inside api
Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Signed-off-by: Tejas Upadhyay <tejas.upadhyay@intel.com>
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patch.msgid.link/20260903161553.528932-30-tejas.upadhyay@intel.com
|
|
Before reserving a page at a faulting address, check the cached
disable_vram_page_offline policy from xe->ras. If the policy is
enabled (logging only), log the corrupted address and return
-EOPNOTSUPP so that RAS can report to firmware to drop the
address from the SRAM queue without attempting to offline the
page.
Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Signed-off-by: Tejas Upadhyay <tejas.upadhyay@intel.com>
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patch.msgid.link/20260903161553.528932-29-tejas.upadhyay@intel.com
|
|
The configfs disable_vram_page_offline attribute can only be
set before device bind, so its value is immutable at runtime.
Cache it in struct xe_drm_ras during xe_ras_init() to avoid
repeated configfs lookups on every fault.
Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Signed-off-by: Tejas Upadhyay <tejas.upadhyay@intel.com>
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patch.msgid.link/20260903161553.528932-28-tejas.upadhyay@intel.com
|
|
Add a new configfs attribute 'disable_vram_page_offline' to control
how bad VRAM pages are handled:
0, n, N, false - Do not disable (Offlining is active - default)
1, y, Y, true - Disable vram page offline (Logging only)
The attribute can only be set before binding to the device and defaults
to false (offlining enabled). This gives administrators control over
whether corrupted VRAM pages detected by hardware (e.g., ECC errors)
are actively offlined or only logged.
v3(Sashiko):
- fix doc
v2(Sashiko):
- keep default value in case configfs not present
Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Signed-off-by: Tejas Upadhyay <tejas.upadhyay@intel.com>
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patch.msgid.link/20260903161553.528932-27-tejas.upadhyay@intel.com
|
|
Add the core VRAM page offlining logic to handle HW-reported faulty
physical addresses:
- xe_ttm_vram_purge_page(): Purges the BO containing the faulty
address. Bans the associated VM (if page table BO) and exec queue
(if LRC BO). Moves xe_exec_queue_kill() outside xe_bo_lock() to
avoid AB-BA deadlock with vm->lock. Uses READ_ONCE(bo->q) to
safely access the exec queue pointer.
- xe_ttm_vram_page_already_processed(): Checks if an address is
already tracked in offlined_pages or queued_pages lists to avoid
double-processing.
- xe_ttm_vram_reserve_page_at_addr(): Two-phase reservation that
first queues the page, purges the BO outside the lock, then
reserves the buddy block. Handles both allocated (BO present)
and free page cases. Returns -EIO for critical kernel BOs to
trigger system reset.
- xe_ttm_vram_addr_to_region(): Maps a DPA to its corresponding
VRAM region. Checks if the address falls within usable space,
or infrastructure zones (CCS, GSM, DSM) where it returns NULL
to flag a reset path. If the target address is outside any
known region returns ERR_PTR(-EOPNOTSUPP)
- xe_ttm_vram_handle_addr_fault(): Entry point called by RAS.
Returns -EEXIST if already processed, -EIO for GSM/critical BO,
-EOPNOTSUPP if out of bounds.
v15:
- Add immediate reservation for free pages
- Use lock before accessing tbo
v14(Sashiko/MattB):
- Retry queued pages during xe_ttm_vram_mgr_del()
- Move all changes to find owner of bo to its API
v13(Himal):
- Remove redundant code
v12(Sashiko):
- Handle multi tile and add assert for 4K align
- Remove unaligned action comment for ENXIO
v11(Himal):
- match everywhere with enum vs bool for status member
- Fix comment and remove unused var
- if purge fail let next alloc confirm failure
- pass absolute address, useful for multi tile
Assisted-by: Copilot:claude-opus-4.6
Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
Signed-off-by: Tejas Upadhyay <tejas.upadhyay@intel.com>
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patch.msgid.link/20260903161553.528932-26-tejas.upadhyay@intel.com
|
|
Add xe_ttm_vram_offline_resource to track individual offlined VRAM
pages, and extend xe_ttm_vram_mgr with offlined_pages/queued_pages
lists and their counters.
Initialize the lists in __xe_ttm_vram_mgr_init() and add
xe_ttm_vram_free_bad_pages() to release all tracked pages during
xe_ttm_vram_mgr_fini() teardown.
v3(Sashiko):
- Reorder xe_ttm_vram_buddy_free and list_del_rcu
- Introduce reservation status
v2(Himal):
- Address possible leak in xe_ttm_vram_mgr_fini()
- Remove unused dev and add comment for used_visible_size 0
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
Signed-off-by: Tejas Upadhyay <tejas.upadhyay@intel.com>
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patch.msgid.link/20260903161553.528932-25-tejas.upadhyay@intel.com
|
|
Factor out xe_ttm_vram_buddy_alloc() and xe_ttm_vram_buddy_free()
from xe_ttm_vram_mgr_new() and xe_ttm_vram_mgr_del().
These new helpers consolidate block allocation/deallocation with
visible-size tracking. This modularization makes the logic reusable by
the upcoming VRAM page offlining reservation path.
No functional change.
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
Signed-off-by: Tejas Upadhyay <tejas.upadhyay@intel.com>
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patch.msgid.link/20260903161553.528932-24-tejas.upadhyay@intel.com
|
|
VRAM page offlining can purge BOs that are still referenced by page
tables, exec queues, and DMA-buf exports. Add xe_bo_is_purged()
guards in the teardown paths to prevent unpinning or mapping an
already-purged BO:
- xe_bo_unpin_map_no_vm(): skip unpin if purged
- xe_dma_buf_map(): return -ENOENT early if purged
- xe_exec_queue_update_run_ticks(): skip LRC timestamp read if purged
- xe_pt_destroy(): skip unpin if purged
v4(Sashiko):
- Move bo purge check in xe_bo_unpin() to handle all instances
v3(Sashiko):
- Remove dma_resv is already held
v2(Himal):
- take dma_resv lock before calling xe_bo_is_purged()
Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
Signed-off-by: Tejas Upadhyay <tejas.upadhyay@intel.com>
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patch.msgid.link/20260903161553.528932-23-tejas.upadhyay@intel.com
|
|
Export xe_bo_is_user() so it can be used by the VRAM page offline
code to distinguish user-created BOs from kernel BOs when deciding
whether a faulty page can be safely purged or requires a full reset.
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
Signed-off-by: Tejas Upadhyay <tejas.upadhyay@intel.com>
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patch.msgid.link/20260903161553.528932-22-tejas.upadhyay@intel.com
|
|
Add NULL checks for the buffer object's resource pointer in
xe_bo_is_vram() and xe_bo_is_stolen() to prevent potential NULL
pointer dereferences when checking memory location during page
offlining.
Additionally, remove the `!ttm_bo->ttm` check from
xe_ttm_bo_purge(). This restriction is stripped away to
explicitly allow the driver to purge VRAM pages during the
memory page offline sequence.
v2(Sashiko):
- Split export and this patch also Check NULL res in
xe_bo_is_vram() and xe_bo_is_stolen()
Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
Cc: Andi Shyti <andi.shyti@linux.intel.com>
Signed-off-by: Tejas Upadhyay <tejas.upadhyay@intel.com>
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patch.msgid.link/20260903161553.528932-21-tejas.upadhyay@intel.com
|
|
Remove the static qualifier from xe_ttm_bo_purge() and add its
prototype to xe_bo.h. This allows the function to be called
from other parts of the driver outside of xe_bo.c, specifically
needed for the memory page offline feature.
Cc: Andi Shyti <andi.shyti@linux.intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Arvind Yadav <arvind.yadav@intel.com>
Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
Signed-off-by: Tejas Upadhyay <tejas.upadhyay@intel.com>
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patch.msgid.link/20260903161553.528932-20-tejas.upadhyay@intel.com
|
|
Introduce an execution queue back-pointer (`q`) within `struct xe_bo`, primarily
for Logical Ring Context (LRC) Buffer Objects. This back-pointer allows the
driver to identify and execute targeted corrective actions on a specific queue
if its associated LRC BO encounters errors like memory corruption or eviction.
Because this back-pointer takes no reference on its target execution queue, strict
lifetime and serialization rules are implemented to prevent concurrent readers
from encountering use-after-free or dangling pointer bugs:
- Encapsulate tracking logic inside xe_exec_queue_set_lrc_bo_backpointer() and
xe_exec_queue_clear_lrc_bo_backpointer().
- Explicitly wrap all back-pointer writes and clears under the BO's dma_resv lock
via xe_bo_lock(). Readers must hold this same lock across both the pointer read
and its subsequent xe_exec_queue_get_unless_zero() call to guarantee serialization
against teardown.
- Defer publishing the back-pointer until the very end of xe_exec_queue_create().
This ensures that early initialization failure paths (which bypass the kref
mechanism and immediately free the queue structure) never leak a transient pointer
to concurrent readers.
- Clear the back-pointer at the absolute top of __xe_exec_queue_fini(). This strips
the pointer before q->ops->fini() destroys the hardware backend, ensuring that
any reader holding the BO lock either observes a fully functional queue or NULL.
For multi-queue engines, secondary LRC BOs safely point to the primary queue, which
is guaranteed to outlive the teardown pass due to active references held by its
secondaries.
V4 (MattB):
- Add LRC BO's execution queue safe lifetime rules
V3 (Sashiko):
- Use 8-byte placeholder structure compatibility for non-LRC BO cases.
- Wrap assignments and clears securely under dma_resv locks.
V2 (Matt B):
- Add native support handling multi-queue configuration tracking.
Assisted-by: Copilot:claude-opus-4.6
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
Signed-off-by: Tejas Upadhyay <tejas.upadhyay@intel.com>
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patch.msgid.link/20260903161553.528932-19-tejas.upadhyay@intel.com
|
|
Setup to link allocation resource structure inside
gpu buddy. This functionality is critical for
supporting the memory page offline feature on CRI,
where identified faulty pages must be traced back to their
originating buffer for safe removal.
v3(MattB): store memory resource(res) instead of tbo
V2(MattB): Clear block->private in xe_ttm_vram_mgr_del as well
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Signed-off-by: Tejas Upadhyay <tejas.upadhyay@intel.com>
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patch.msgid.link/20260903161553.528932-18-tejas.upadhyay@intel.com
|
|
Starting with Rust 1.100.0 (expected 2026-11-12), Clippy warns:
warning: the loop variable `i` is only used to index `self.decimals`
--> drivers/gpu/drm/drm_panic_qr.rs:410:18
|
410 | for i in 0..len {
| ^^^^^^
|
note: for this index operation
--> drivers/gpu/drm/drm_panic_qr.rs:411:13
|
411 | self.decimals[i] = (chunk % 10) as u8;
| ^^^^^^^^^^^^^^^^
= help: for further information visit https://rust-lang.github.io/rust-clippy/main/index.html#needless_range_loop
= note: `-W clippy::needless-range-loop` implied by `-W clippy::all`
= help: to override `-W clippy::all` add `#[allow(clippy::needless_range_loop)]`
help: consider using an iterator
|
410 - for i in 0..len {
410 + for <item> in self.decimals.iter_mut().take(len) {
|
The lint did not trigger here before because it could not handle arrays
behind a field access such as `self.decimals` -- Clippy was improved to
catch those cases [1][2].
Thus clean the warning by iterating over a slice rather than using
`take()` so that an out-of-range `len` still triggers the same bounds
check as the indexed loop.
Cc: stable@vger.kernel.org # Needed in 6.18.y and later.
Link: https://github.com/rust-lang/rust-clippy/issues/16631 [1]
Link: https://github.com/rust-lang/rust-clippy/pull/16634 [2]
Assisted-by: LLM
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://patch.msgid.link/20260826145642.43807-1-ojeda@kernel.org
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
|
|
Add the SRCID of the faulting hardware unit to the return of the
xe_vm_get_property_ioctl fault report.
v2:
- Readd pad check, as the pad in the ioctl struct was not changed
(jcavitt)
v3:
- Squash SRCID with ASID to keep the struct compact (Matthew)
Signed-off-by: Jonathan Cavitt <jonathan.cavitt@intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: David Airlie <airlied@gmail.com>
Cc: Simona Vetter <simona@ffwll.ch>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patch.msgid.link/20260902214358.348399-3-jonathan.cavitt@intel.com
|
|
Add SRCID information to pagefault struct for the purpose of reporting
the hardware unit that resulted in the pagefault.
v2:
- Squash SRCID with ASID to keep the struct compact (Matthew)
v3:
- Use BUILD_BUG_ON and move ASID definition in one function (Matthew)
v4:
- Various formatting fixes
Signed-off-by: Jonathan Cavitt <jonathan.cavitt@intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: David Airlie <airlied@gmail.com>
Cc: Simona Vetter <simona@ffwll.ch>
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patch.msgid.link/20260902214358.348399-2-jonathan.cavitt@intel.com
|
|
So we can easily check if a machine had the CCS bug, when looking back
over bug reports where we have the same machine with newer kernel.
Example print for a machine with the CCS bug:
FLAT_CCS base:27bbff800, aligned:no
v2 (Matt B):
- Unconditionally print the base + alignment
Fixes: 37173392741c ("drm/xe/vram: fix ccs offset calculation")
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: stable@kernel.org
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patch.msgid.link/20260902124117.918018-9-matthew.auld@intel.com
(cherry picked from commit d00b7f4f03bbeb2efad872f1686130e18c2b4141)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
|
rk3066_hdmi.c calls drm_bridge_connector_init(), but
ROCKCHIP_RK3066_HDMI selects neither DRM_BRIDGE_CONNECTOR nor
DRM_DISPLAY_HELPER, whose module carries the bridge-connector code. A
configuration with ROCKCHIP_RK3066_HDMI as the only enabled Rockchip
output option fails to link:
aarch64-linux-gnu-ld: drivers/gpu/drm/rockchip/rk3066_hdmi.o: in function `rk3066_hdmi_bind':
rk3066_hdmi.c:(.text+0x7a4): undefined reference to `drm_bridge_connector_init'
aarch64-linux-gnu-ld: drivers/gpu/drm/rockchip/rk3066_hdmi.o: in function `rk3066_hdmi_bridge_atomic_enable':
rk3066_hdmi.c:(.text+0xe74): undefined reference to `drm_atomic_helper_connector_hdmi_update_infoframes'
Select both, like ROCKCHIP_CDN_DP, ROCKCHIP_LVDS and ROCKCHIP_RGB do.
DRM_BRIDGE_CONNECTOR in turn selects DRM_DISPLAY_HDMI_STATE_HELPER,
which resolves the second symbol.
Fixes: 57d6811e8a6d ("drm/rockchip: rk3066_hdmi: switch to drm bridge")
Signed-off-by: Igor Paunovic <royalnet026@gmail.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patch.msgid.link/20260813144019.12089-3-royalnet026@gmail.com
|
|
dw_dp-rockchip.c calls drm_bridge_connector_init(), but ROCKCHIP_DW_DP
does not select DRM_BRIDGE_CONNECTOR. A configuration with
ROCKCHIP_DW_DP as the only enabled Rockchip output option fails to
link:
aarch64-linux-gnu-ld: drivers/gpu/drm/rockchip/dw_dp-rockchip.o: in function `dw_dp_rockchip_bind':
dw_dp-rockchip.c:(.text+0x1d4): undefined reference to `drm_bridge_connector_init'
Five other Rockchip encoder options that call
drm_bridge_connector_init() (ROCKCHIP_ANALOGIX_DP, ROCKCHIP_CDN_DP,
ROCKCHIP_DW_HDMI_QP, ROCKCHIP_LVDS, ROCKCHIP_RGB) already select it,
which masks the gap in any configuration that enables one of them.
ROCKCHIP_INNO_HDMI is covered through its DRM_INNO_HDMI core option.
The same change was posted by Marius Dinu in March and dropped when
the failure stopped reproducing in his build. The failure is
configuration-dependent - any other enabled option that selects
DRM_BRIDGE_CONNECTOR hides it - and it still reproduces on current
drm-misc-next with the configuration described above.
Select DRM_BRIDGE_CONNECTOR like the other users do.
Fixes: d68ba7bac955 ("drm/rockchip: Add RK3588 DPTX output support")
Link: https://lore.kernel.org/r/aneNCDU12OzG99UX@venus # ack to handle this apart from the dw-dp series
Link: https://lore.kernel.org/r/20260319155051.1944-1-m95d+git@psihoexpert.ro # earlier submission by Marius Dinu
Signed-off-by: Igor Paunovic <royalnet026@gmail.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patch.msgid.link/20260813144019.12089-2-royalnet026@gmail.com
|
|
dw_hdmi_qp_set_sample_rate() open-coded its own N and CTS lookup
tables and search/compute helpers, but it lacked the out-of-table
CTS fallback needed by strict HDMI sinks at TMDS rates not in the
table. The original LG G3 OLED audio mute (linux-rockchip 070633)
was caused by dw_hdmi_qp_find_cts() returning 0 at 185.625 MHz,
leaving AUDPKT_ACR_CTS_OVR_EN clear and falling back to the
controller's internal CTS auto-measurement, which produces incorrect
timing on the wire at out-of-table rates.
The shared drm_hdmi_acr_get_n_cts() helper in
drivers/gpu/drm/display/drm_hdmi_helper.c already implements the
correct behaviour: it has the HDMI 1.4b spec N/CTS tables, and for
TMDS rates not in the table it computes CTS = (TMDS * N) / (128 * Fs)
inline (the canonical HDMI spec formula). It is already used by
drivers/gpu/drm/msm/hdmi/hdmi_audio.c.
Convert dw_hdmi_qp_set_sample_rate() to call the helper. This
removes ~200 lines of open-coded tables and search functions
(dw_hdmi_qp_find_n, _compute_n, _find_cts, _audio_math_diff,
_match_tmds_n_table, common_tmds_n_table[], common_tmds_cts_table[])
and fixes the strict-sink audio mute as a side effect of using the
helper's complete N+CTS path.
Tested on R76S (RK3576) running Linux 7.0.1, against the LG G3 OLED
(the sink that originally reported the mute in linux-rockchip
070633) at four TMDS rates spanning HDMI 1.4 and HDMI 2.0:
TMDS Mode Audio with v3
148.5 MHz 1080p60 8-bit plays
185.625 MHz 1080p60 10-bit plays
297 MHz 1080p100 8-bit plays
594 MHz 3840p60 8-bit plays
Without this change, the LG G3 mutes audio at 185.625, 297, and
594 MHz (every rate outside dw-hdmi-qp's open-coded CTS table,
which contained only 148.5 MHz and below). With this change,
drm_hdmi_acr_get_n_cts() supplies the correct CTS at every rate --
table-canonical at 148.5 / 297 / 594 MHz, and computed via the
HDMI 1.4b formula at 185.625 MHz. The 148.5 MHz row is a
regression check confirming the in-table path is unchanged.
The Kogan KALED43XU9210STA (a permissive HDMI 2.0 sink that plays
audio at all rates with or without this change) was used as a
no-regression control: audio plays at 594 MHz with v3 loaded.
The open-coded N table in dw-hdmi-qp included optimised N values
for some TMDS rates that are not in the helper's table (e.g.
various non-CEA rates between 28-162 MHz). For those rates the
helper's fallback returns N = 128 * Fs / 1000, which is the same
value dw_hdmi_qp_compute_n() returned when no table optimisation
was needed; no audio regression has been observed at the rates
tested above.
Reported-by: Simon Wright <simon@symple.nz>
Closes: https://lore.kernel.org/linux-rockchip/ME3P282MB21960D9D68BFF520316BDFCEA83E2@ME3P282MB2196.AUSP282.PROD.OUTLOOK.COM/
Suggested-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Suggested-by: Jonas Karlman <jonas@kwiboo.se>
Assisted-by: Claude:claude-opus-4-7
Signed-off-by: Simon Wright <simon@symple.nz>
Tested-by: Igor Paunovic <royalnet026@gmail.com> # RK3588 Orange Pi 5 Plus, both HDMI controllers
Tested-by: Christian Hewitt <christianshewitt@gmail.com>
Reviewed-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Tested-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patch.msgid.link/86fcf349-0a7a-4618-9001-612371b0f71b@symple.nz
|
|
Commit 3392291fc509 ("drm/msm: Fix shrinker deadlock") dropped the only
use of the ticket arg, but at the time left drm_gem_lru_scan() unchanged
to avoid conflicts with in-flight panthor shrinker support. This commit
is the followup to remove the unused arg.
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Liviu Dudau <liviu.dudau@arm.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patch.msgid.link/20260901164544.642985-1-robin.clark@oss.qualcomm.com
|
|
rockchip_dp_drm_encoder_enable() uses sprintf() to format a device tree
path into a 32-byte stack buffer. Device tree paths are not limited to
this size, so a sufficiently long path can overflow the buffer.
Use snprintf() with the destination size to truncate the generated name
and keep the writes within bounds.
Fixes: 729f8eefdcad ("drm/rockchip: analogix_dp: Add support for RK3588")
Cc: stable@vger.kernel.org
Signed-off-by: Yudi Yang <2000jedi@gmail.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patch.msgid.link/20260901195511.2761251-1-2000jedi@gmail.com
|
|
dispc_plane_state_dma_addr() and dispc_plane_state_p_uv_addr() are
basically the same as drm_fb_dma_get_gem_addr(), without the support for
formats with block parameters. Since the driver doesn't support any of
those formats, the result is the same.
Switch to drm_fb_dma_get_gem_addr() for getting the framebuffer addresses.
Drop the const modifier on "struct drm_plane_state *state" for
dispc_plane_setup() so that the state can be passed to
drm_fb_dma_get_gem_addr().
Using the helper also future proofs the driver in case block parameters
are added for more formats, especially the common sub-sampled YUV
formats.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Link: https://patch.msgid.link/20260903063142.3770509-1-wenst@chromium.org
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
|
|
During early probe, use the last page as a canary for BAR sizing, CCS
sizing, identity map setup etc. If something is wrong the last page is
where we will likely find it. Hit it with everything we have. For now
this is gated behind a debug config option, so shouldn't trigger on
production.
Main motivation is around CCS sizing where on some BMG cards the CCS
offset is programmed misaligned, for whatever reason, and our handling
of that was busted, as found by Linus, leading to some amount of CCS
storage getting pulled into the allocator as normal VRAM.
Nothing in our CI farm has such a misaligned offset it would seem,
however I did get this to pop on my b570, which does also have the
misaligned CCS offset:
Tile 0: Running VRAM memtest...
Tile 0: VRAM bounds overlap CCS region! VRAM sizing is incorrect.
With the fix from Linus, this goes away:
Tile 0: Running VRAM memtest...
Tile 0: VRAM memtest completed.
For the VRAM health check itself, this adds:
- CPU access to the last page (BAR).
- GPU access to the last page (identity map).
- CCS overlap check. This one is more involved, but overall idea is
fill the last page with a known pattern, and also save the CCS state
for the first 4M of VRAM to some scratch memory. We then zero the CCS
storage for that same range, all using the proper CCS copy instruction.
At this point we readback the last page, and check if the pattern we
wrote changed. Finally we restore the CCS state. This works since CCS
1:1 maps with VRAM, so the start of the raw CCS, should map to the
start of VRAM. This successfully catches the issue that Linus found
and fixed.
Assisted-by: Gemini:gemini-3.1-pro-preview
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Stuart Summers <stuart.summers@intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patch.msgid.link/20260902124117.918018-12-matthew.auld@intel.com
|
