Dave Airlie [Fri, 2 May 2025 04:23:29 +0000 (14:23 +1000)]
Merge tag 'drm-misc-next-2025-04-29' of https://gitlab.freedesktop.org/drm/misc/kernel into drm-next
drm-misc-next for v6.16-rc1:
UAPI Changes:
- panthor now fails in mmap_offset call for a BO created with
DRM_PANTHOR_BO_NO_MMAP.
- Add DRM_PANTHOR_BO_SET_LABEL ioctl and label panthor kernel BOs.
Cross-subsystem Changes:
- Add kmap_local_page_try_from_panic for drm/panic.
- Add DT bindings for panels.
- Update DT bindings for imagination.
- Extend %p4cc in lib/vsprintf.c to support fourcc printing.
Core Changes:
- Remove the disgusting turds.
- Register definition updates for DP.
- DisplayID timing blocks refactor.
- Remove now unused mipi_dsi_dsc_write_seq.
- Convert panel drivers to not return error in prepare/enable and
unprepare/disable calls.
Driver Changes:
- Assorted small fixes and featuers for rockchip, panthor, accel/ivpu,
accel/amdxdna, hisilicon/hibmc, i915/backlight, sysfb, accel/qaic,
udl, etnaviv, virtio, xlnx, panel/boe-bf060y8m-aj0, bridge/synopsis,
panthor, panel/samsung/sofef00m, lontium/lt9611uxc, nouveau, panel/himax-hx8279,
panfrost, st7571-i2c.
- Improve hibmc interrupt handling and add HPD support.
- Add NLT NL13676BC25-03F, Tianma TM070JDHG34-00, Himax HX8279/HX8279-D
DDIC, Visionox G2647FB105, Sitronix ST7571 LCD Controller, panels.
- Add zpos, alpha and blend to renesas.
- Convert drivers to use drm_gem_is_imported, replacing gem->import_attach.
- Support TI AM68 GPU in imagination.
- Support panic handler in virtio.
- Add support to get the panel from DP AUX bus in rockchip and add
RK3588 support.
- Make sofef00 only support the sofef00 panel, not another unrelated
one.
- Add debugfs BO dumping support to panthor, and print associated labels.
- Implement heartbeat based hangcheck in ivpu.
- Mass convert drivers to devm_drm_bridge_alloc api.
drm/bridge: imx8*-ldb: convert to devm_drm_bridge_alloc() API
This is the new API for allocating DRM bridges.
These two drivers are tangled together by the ldb_add_bridge_helper(), so
they are converted at once.
They also have a similar design, each embedding an array of channels in
their main struct, and each channel embeds a drm_bridge. This prevents
dynamic, refcount-based deallocation of the bridges.
To make the new, dynamic bridge allocation possible:
* change the array of channels into an array of channel pointers
* allocate each channel using devm_drm_bridge_alloc()
* adapt ldb_add_bridge_helper() to not set the funcs pointer
(now done by devm_drm_bridge_alloc())
* adapt the code wherever using the channels
This driver already implements refcounting of the struct vc4_dsi, which
embeds struct drm_bridge. Now this is a duplicate of the refcounting
implemented by the DRM bridge core, so convert the vc4_dsi_get/put() calls
into drm_bridge_get/put() calls and get rid of the driver-specific
refcounting implementation.
Driver Changes:
- Do not queue unneeded terminations from debugfs (Daniele)
- Fix out-of-bound while enabling engine activity stats (Michal)
- Use GT oriented message to report engine activity error (Michal)
- Some fault-injection additions (Satyanarayana)
- Fix an error pointer dereference (Harshit)
- Fix capture of steering registers (John)
- Use the steering flag when printing registers (John)
- Cache DSS info when creating capture register list (John)
- Backup VRAM in PM notifier instead of in the suspend / freeze
callbacks (Matt Auld)
- Fix CFI violation when accessing sysfs files (Jeevaka)
- Fix kernel version docs for temperature and fan speed (Lucas)
- Add devcoredump chunking (Matt Brost)
- Update xe_ttm_access_memory to use GPU for non-visible access
(Matt Brost)
- Abort printing coredump in VM printer output if full (Matt Brost)
- Resolve a possible circular locking dependency (Harish)
- Don't support EU stall on SRIOV VF (Harish)
- Drop force_alloc from xe_bo_evict in selftests (Matt Brost)
Philippe Simons [Thu, 3 Apr 2025 05:52:09 +0000 (07:52 +0200)]
drm/panfrost: add h616 compatible string
Tie the Allwinner compatible string to the GPU_PM_RT feature bits that will
toggle the clocks and the reset line whenever the power domain is changing
state.
Matthew Brost [Mon, 28 Apr 2025 02:23:18 +0000 (19:23 -0700)]
drm/xe: Drop force_alloc from xe_bo_evict in selftests
The force_alloc flag was removed from TTM / Xe but updating the
selftests to new function interfaces was missed. Remove argument from
xe_bo_evict in selftests.
Jose Maria Casanova Crespo [Fri, 25 Apr 2025 12:25:07 +0000 (14:25 +0200)]
drm/v3d: fix client obtained from axi_ids on V3D 4.1
In the case of MMU errors caused by the TFU unit, the
client that causes the MMU error is expected to be reported.
But in the case of MMU TFU errors, a non existing client was
being reported. This happened because the client calculation
was taking into account more than the bits 0-7 from the
axi_id that were representing the client.
[ 27.845132] v3d fec00000.v3d: MMU error from client ? (13) at 0x3bb1000, pte invalid
Masking the bits and using the correct axi_id ranges fixes the
calculation to report the real guilty client on V3D 4.1 and 4.2.
Make the MMU error print axi_id with hexadecimal as used in the
ranges.
Fixes: 38c2c7917adc ("drm/v3d: Fix and extend MMU error handling.") Signed-off-by: Jose Maria Casanova Crespo <jmcasanova@igalia.com> Reviewed-by: Maíra Canal <mcanal@igalia.com> Link: https://lore.kernel.org/r/20250425122522.18425-1-jmcasanova@igalia.com Signed-off-by: Maíra Canal <mcanal@igalia.com>
drm/xe/eustall: Resolve a possible circular locking dependency
Use a separate lock in the polling function eu_stall_data_buf_poll()
instead of eu_stall->stream_lock. This would prevent a possible
circular locking dependency leading to a deadlock as described below.
This would also require additional locking with the new lock in
the read function.
<4> [787.192986] ======================================================
<4> [787.192988] WARNING: possible circular locking dependency detected
<4> [787.192991] 6.14.0-rc7-xe+ #1 Tainted: G U
<4> [787.192993] ------------------------------------------------------
<4> [787.192994] xe_eu_stall/20093 is trying to acquire lock:
<4> [787.192996] ffff88819847e2c0 ((work_completion)
(&(&stream->buf_poll_work)->work)), at: __flush_work+0x1f8/0x5e0
<4> [787.193005] but task is already holding lock:
<4> [787.193007] ffff88814ce83ba8 (>->eu_stall->stream_lock){3:3},
at: xe_eu_stall_stream_ioctl+0x41/0x6a0 [xe]
<4> [787.193090] which lock already depends on the new lock.
<4> [787.193093] the existing dependency chain (in reverse order) is:
<4> [787.193095]
-> #1 (>->eu_stall->stream_lock){+.+.}-{3:3}:
<4> [787.193099] __mutex_lock+0xb4/0xe40
<4> [787.193104] mutex_lock_nested+0x1b/0x30
<4> [787.193106] eu_stall_data_buf_poll_work_fn+0x44/0x1d0 [xe]
<4> [787.193155] process_one_work+0x21c/0x740
<4> [787.193159] worker_thread+0x1db/0x3c0
<4> [787.193161] kthread+0x10d/0x270
<4> [787.193164] ret_from_fork+0x44/0x70
<4> [787.193168] ret_from_fork_asm+0x1a/0x30
<4> [787.193172]
-> #0 ((work_completion)(&(&stream->buf_poll_work)->work)){+.+.}-{0:0}:
<4> [787.193176] __lock_acquire+0x1637/0x2810
<4> [787.193180] lock_acquire+0xc9/0x300
<4> [787.193183] __flush_work+0x219/0x5e0
<4> [787.193186] cancel_delayed_work_sync+0x87/0x90
<4> [787.193189] xe_eu_stall_disable_locked+0x9a/0x260 [xe]
<4> [787.193237] xe_eu_stall_stream_ioctl+0x5b/0x6a0 [xe]
<4> [787.193285] __x64_sys_ioctl+0xa4/0xe0
<4> [787.193289] x64_sys_call+0x131e/0x2650
<4> [787.193292] do_syscall_64+0x91/0x180
<4> [787.193295] entry_SYSCALL_64_after_hwframe+0x76/0x7e
<4> [787.193299]
other info that might help us debug this:
<4> [787.193302] Possible unsafe locking scenario:
<4> [787.193304] CPU0 CPU1
<4> [787.193305] ---- ----
<4> [787.193306] lock(>->eu_stall->stream_lock);
<4> [787.193308] lock((work_completion)
(&(&stream->buf_poll_work)->work));
<4> [787.193311] lock(>->eu_stall->stream_lock);
<4> [787.193313] lock((work_completion)
(&(&stream->buf_poll_work)->work));
<4> [787.193315]
*** DEADLOCK ***
Fixes: 760edec939685 ("drm/xe/eustall: Add support to read() and poll() EU stall data") Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/4598 Signed-off-by: Harish Chegondi <harish.chegondi@intel.com> Reviewed-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Link: https://lore.kernel.org/r/c896932fca84f79db2df5942911997ed77b2b9b6.1744934656.git.harish.chegondi@intel.com
Dave Airlie [Fri, 25 Apr 2025 22:06:02 +0000 (08:06 +1000)]
Merge tag 'drm-xe-next-2025-04-17' of https://gitlab.freedesktop.org/drm/xe/kernel into drm-next
Core Changes:
Fix drm_gpusvm kernel-doc (Lucas)
Driver Changes:
- Release guc ids before cancelling work (Tejas)
- Remove a duplicated pc_start_call (Rodrigo)
- Fix an incorrect assert in previous userptr fixes (Thomas)
- Remove gen11 assertions and prefixes (Lucas)
- Drop sentinels from arg to xe_rtp_process_to_src (Lucas)
- Temporarily disable D3Cold on BMG (Rodrigo)
- Fix MOCS debugfs LNCF readout (Tvrtko)
- Some ring flush cleanups (Tvrtko)
- Use unsigned int for alignment in fb pinning code (Tvrtko)
- Retry and wait longer for GuC PC start (Rodrigo)
- Recognize 3DSTATE_COARSE_PIXEL in LRC dumps (Matt Roper)
- Remove reduntant check in xe_vm_create_ioctl() (Xin)
- A bunch of SRIOV updates (Michal)
- Add stats for SVM page-faults (Francois)
- Fix an UAF (Harish)
- Expose fan speed (Raag)
- Fix exporting xe buffer objects multiple times (Tomasz)
- Apply a workaround (Vinay)
- Simplify pinned bo iteration (Thomas)
- Remove an incorrect "static" keywork (Lucas)
- Add support for separate firmware files on each GT (Lucas)
- Survivability handling fixes (Lucas)
- Allow to inject error in early probe (Lucas)
- Fix unmet direct dependencies warning (Yue Haibing)
- More error injection during probe (Francois)
- Coding style fix (Maarten)
- Additional stats support (Riana)
- Add fault injection for xe_oa_alloc_regs (Nakshrtra)
- Add a BMG PCI ID (Matt Roper)
- Some SVM fixes and preliminary SVM multi-device work (Thomas)
- Switch the migrate code from drm managed to dev managed (Aradhya)
- Fix an out-of-bounds shift when invalidating TLB (Thomas)
- Ensure fixed_slice_mode gets set after ccs_mode change (Niranjana)
- Use local fence in error path of xe_migrate_clear (Matthew Brost)
- More Workarounds (Julia)
- Define sysfs_ops on all directories (Tejas)
- Set power state to D3Cold during s2idle/s3 (Badal)
- Devcoredump output fix (John)
- Avoid plain 64-bit division (Arnd Bergmann)
- Reword a debug message (John)
- Don't print a hwconfig error message when forcing execlists (Stuart)
- Restore an error code to avoid a smatch warning (Rodrigo)
- Invalidate L3 read-only cachelines for geometry streams too (Kenneth)
- Make PPHWSP size explicit in xe_gt_lrc_size() (Gustavo)
- Add GT frequency events (Vinay)
- Fix xe_pt_stage_bind_walk kerneldoc (Thomas)
- Add a workaround (Aradhya)
- Rework pinned save/restore (Matthew Auld, Matthew Brost)
- Allow non-contig VRAM kernel BO (Matthew Auld)
- Support non-contig VRAM provisioning for SRIOV (Matthew Auld)
- Allow scratch-pages for unmapped parts of page-faulting VMs. (Oak)
- Ensure XE_BO_FLAG_CPU_ADDR_MIRROR had a unique value (Matt Roper)
- Fix taking an invalid lock on wedge (Lucas)
- Configs and documentation for survivability mode (Riana)
- Remove an unused macro (Shuicheng)
- Work around a page-fault full error (Matt Brost)
- Enable a SRIOV workaround (John)
- Bump the recommended GuC version (John)
- Allow to drop VRAM resizing (Lucas)
- Don't expose privileged debugfs files if VF (Michal)
- Don't show GGTT/LMEM debugfs files under media GT (Michal)
- Adjust ring-buffer emission for maximum possible size (Tvrtko)
- Fix notifier vs folio lock deadlock (Matthew Auld)
- Stop relying on placement for dma-buf unmap Matthew Auld)
Introduce a heartbeat-based Timeout Detection and Recovery (TDR) mechanism.
The enhancement aims to improve the reliability of device hang detection by
monitoring heartbeat updates.
Each progressing inference will update heartbeat counter allowing driver to
monitor its progression. Limit maximum number of reschedules when heartbeat
indicates progression to 30. This increases the maximum running time of
single inference to about 60 seconds.
The heartbeat mechanism provides a more robust method for detecting device
hangs, potentially reducing false positive recoveries due to long running
inferences.
Signed-off-by: Karol Wachowski <karol.wachowski@intel.com> Signed-off-by: Maciej Falkowski <maciej.falkowski@linux.intel.com> Reviewed-by: Jeff Hugo <jeff.hugo@oss.qualcomm.com> Signed-off-by: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com> Link: https://lore.kernel.org/r/20250416102555.384526-1-maciej.falkowski@linux.intel.com
Matthew Brost [Wed, 23 Apr 2025 17:17:24 +0000 (10:17 -0700)]
drm/print: Add drm_coredump_printer_is_full
Add drm_coredump_printer_is_full which indicates if a drm printer's
output is full. Useful to short circuit coredump printing once printer's
output is full.
v2:
- s/drm_printer_is_full/drm_coredump_printer_is_full (Jani)
v3:
- Bail if not a coredump printer (Michal)
Matthew Brost [Wed, 23 Apr 2025 17:17:23 +0000 (10:17 -0700)]
drm/xe: Update xe_ttm_access_memory to use GPU for non-visible access
Add migrate layer functions to access VRAM and update
xe_ttm_access_memory to use for non-visible access and large (more than
16k) BO access. 8G devcoreump on BMG observed 3 minute CPU copy time vs.
3s GPU copy time.
v4:
- Fix non-page aligned accesses
- Add support for small / unaligned access
- Update commit message indicating migrate used for large accesses (Auld)
- Fix warning in xe_res_cursor for non-zero offset
v5:
- Fix 32 bit build (CI)
v6:
- Rebase and use SVM migration copy functions
v7:
- Fix build error (CI)
v8:
- Remove ifdef around VRAM copy functions (CI)
- Use break statement in dma unmmaping (Jonathan)
- Use if/else rather than goto (Jonathan)
- Use single return point (Jonathan)
Matthew Brost [Wed, 23 Apr 2025 17:17:22 +0000 (10:17 -0700)]
drm/xe: Add devcoredump chunking
Chunk devcoredump into 1.5G pieces to avoid hitting the kvmalloc limit
of 2G. Simple algorithm reads 1.5G at time in xe_devcoredump_read
callback as needed.
Some memory allocations are changed to GFP_ATOMIC as they done in
xe_devcoredump_read which holds lock in the path of reclaim. The
allocations are small, so in practice should never fail.
v2:
- Update commit message wrt gfp atomic (John H)
v6:
- Drop GFP_ATOMIC change for hwconfig (John H)
Lucas De Marchi [Mon, 21 Apr 2025 15:15:39 +0000 (08:15 -0700)]
drm/xe/hwmon: Fix kernel version documentation for fan speed
The version in the sysfs attribute should correspond to the version in
which this is enabled and visible for end users. It usually doesn't
correspond to the version in which the patch was developed, but rather a
release that will contain it. Update them to 6.16.
Fixes: 28f79ac609de ("drm/xe/hwmon: expose fan speed") Reported-by: Ulisses Furquim <ulisses.furquim@intel.com> Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/4841 Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Raag Jadav <raag.jadav@intel.com> Link: https://lore.kernel.org/r/20250421-hwmon-doc-fix-v1-2-9f68db702249@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Lucas De Marchi [Mon, 21 Apr 2025 15:15:38 +0000 (08:15 -0700)]
drm/xe/hwmon: Fix kernel version documentation for temperature
The version in the sysfs attribute should correspond to the version in
which this is enabled and visible for end users. It usually doesn't
correspond to the version in which the patch was developed, but rather a
release that will contain it. Update them to 6.15.
Fixes: dac328dea701 ("drm/xe/hwmon: expose package and vram temperature") Reported-by: Ulisses Furquim <ulisses.furquim@intel.com> Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/4840 Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Raag Jadav <raag.jadav@intel.com> Link: https://lore.kernel.org/r/20250421-hwmon-doc-fix-v1-1-9f68db702249@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Michal Wilczynski [Fri, 18 Apr 2025 11:22:49 +0000 (13:22 +0200)]
drm/imagination: Add reset controller support for GPU initialization
All IMG Rogue GPUs include a reset line that participates in the
power-up sequence. On some SoCs (e.g., T-Head TH1520 and Banana Pi
BPI-F3), this reset line is exposed and must be driven explicitly to
ensure proper initialization. On others, such as the currently
supported TI SoC, the reset logic is handled in hardware or firmware
without exposing the line directly. In platforms where the reset line is
externally accessible, if it is not driven correctly, the GPU may remain
in an undefined state, leading to instability or performance issues.
This commit adds a dedicated reset controller to the drm/imagination
driver. By managing the reset line (where applicable) as part of normal
GPU bring-up, the driver ensures reliable initialization across
platforms regardless of whether the reset is controlled externally or
handled internally.
Michal Wilczynski [Fri, 18 Apr 2025 11:22:48 +0000 (13:22 +0200)]
dt-bindings: gpu: Add 'resets' property for GPU initialization
All IMG Rogue GPUs include a reset line that participates in the
power-up sequence. On some SoCs (e.g., T-Head TH1520 and Banana Pi
BPI-F3), this reset line is exposed and must be driven explicitly to
ensure proper initialization.
To support this, add a 'resets' property to the GPU device tree
bindings.
When CONFIG_DEBUG_FS is disabled, the stid_fmts[] array is not referenced
anywhere, causing a W=1 warning with gcc:
In file included from drivers/gpu/drm/imagination/pvr_fw_trace.c:7:
drivers/gpu/drm/imagination/pvr_rogue_fwif_sf.h:75:39: error: 'stid_fmts' defined but not used [-Werror=unused-const-variable=]
75 | static const struct rogue_km_stid_fmt stid_fmts[] = {
| ^~~~~~~~~
Rather than adding more #ifdef blocks, address this by changing the
existing #ifdef into equivalent IS_ENABLED() checks so gcc can see
where the symbol is used but still eliminate it from the object file.
drm/panel: himax-hx8279: Always initialize goa_{even,odd}_valid in hx8279_check_goa_config()
Clang warns (or errors with CONFIG_WERROR=y):
drivers/gpu/drm/panel/panel-himax-hx8279.c:838:6: error: variable 'goa_even_valid' is used uninitialized whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized]
838 | if (num_zero == ARRAY_SIZE(desc->goa_even_timing))
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/gpu/drm/panel/panel-himax-hx8279.c:842:23: note: uninitialized use occurs here
842 | if (goa_odd_valid != goa_even_valid)
| ^~~~~~~~~~~~~~
drivers/gpu/drm/panel/panel-himax-hx8279.c:838:2: note: remove the 'if' if its condition is always true
838 | if (num_zero == ARRAY_SIZE(desc->goa_even_timing))
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
839 | goa_even_valid = false;
drivers/gpu/drm/panel/panel-himax-hx8279.c:818:36: note: initialize the variable 'goa_even_valid' to silence this warning
818 | bool goa_odd_valid, goa_even_valid;
| ^
| = 0
Even though only the even valid variable gets flagged, both valid
variables appear to have the same issue of possibly being used
uninitialized if the if statement initializing them to false is not
taken.
Turn the if statement then variable assignment into a single variable
assignment, which states that the configuration is valid when there are
not all zeros, clearing up the warning since the variable will always be
initialized.
Dave Airlie [Wed, 23 Apr 2025 02:21:38 +0000 (12:21 +1000)]
drm/ttm/xe: drop unused force_alloc flag
This flag used to be used in the old memory tracking code, that
code got migrated into the vmwgfx driver[1], and then got removed
from the tree[2], but this piece got left behind.
[1] f07069da6b4c ("drm/ttm: move memory accounting into vmwgfx v4")
[2] 8aadeb8ad874 ("drm/vmwgfx: Remove the dedicated memory accounting")
Cleanup the dead code.
Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Marcus Folkesson [Wed, 23 Apr 2025 19:03:22 +0000 (21:03 +0200)]
MAINTAINERS: add entry for Sitronix ST7571 LCD Controller
Add MAINTAINERS entry for the Sitronix ST7571 dot matrix LCD
controller.
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Marcus Folkesson <marcus.folkesson@gmail.com> Link: https://lore.kernel.org/r/20250423-st7571-v6-3-e9519e3c4ec4@gmail.com Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Marcus Folkesson [Wed, 23 Apr 2025 19:03:21 +0000 (21:03 +0200)]
drm/st7571-i2c: add support for Sitronix ST7571 LCD controller
Sitronix ST7571 is a 4bit gray scale dot matrix LCD controller.
The controller has a SPI, I2C and 8bit parallel interface, this
driver is for the I2C interface only.
Reviewed-by: Thomas Zimmermann <tzimmrmann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Marcus Folkesson <marcus.folkesson@gmail.com> Link: https://lore.kernel.org/r/20250423-st7571-v6-2-e9519e3c4ec4@gmail.com Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
drm/xe: Fix CFI violation when accessing sysfs files
When an attribute group is created with sysfs_create_group() or
sysfs_create_files() the ->sysfs_ops() callback is set to
kobj_sysfs_ops, which sets the ->show() callback to kobj_attr_show().
kobj_attr_show() uses container_of() to get the ->show() callback
from the attribute it was passed, meaning the ->show() callback needs
to be the same type as the ->show() callback in 'struct kobj_attribute'.
However, cur_freq_show() has the type of the ->show() callback in
'struct device_attribute', which causes a CFI violation when opening the
'id' sysfs node under gtidle/freq/throttle. This happens to work because
the layout of 'struct kobj_attribute' and 'struct device_attribute' are
the same, so the container_of() cast happens to allow the ->show()
callback to still work.
Changed the type of cur_freq_show() and few more functions to match the
->show() callback in 'struct kobj_attributes' to resolve the CFI
violation.
CFI failure seen while accessing sysfs files under
/sys/class/drm/card0/device/tile0/gt*/gtidle/*
/sys/class/drm/card0/device/tile0/gt*/freq0/*
/sys/class/drm/card0/device/tile0/gt*/freq0/throttle/*
-Wflex-array-member-not-at-end was introduced in GCC-14, and we are
getting ready to enable it, globally.
Use the `DEFINE_RAW_FLEX()` helper for a few on-stack definitions
of a flexible structure where the size of the flexible-array member
is known at compile-time, and refactor the rest of the code,
accordingly.
So, with these changes, fix the following warnings:
drivers/gpu/drm/nouveau/nouveau_chan.c:274:37: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
drivers/gpu/drm/nouveau/nouveau_chan.c:371:46: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
drivers/gpu/drm/nouveau/nouveau_chan.c:524:42: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
drm/panthor: show device-wide list of DRM GEM objects over DebugFS
Add a device DebugFS file that displays a complete list of all the DRM
GEM objects that are exposed to UM through a DRM handle.
Since leaking object identifiers that might belong to a different NS is
inadmissible, this functionality is only made available in debug builds
with DEBUGFS support enabled.
File format is that of a table, with each entry displaying a variety of
fields with information about each GEM object.
Each GEM object entry in the file displays the following information
fields: Client PID, BO's global name, reference count, BO virtual size,
BO resize size, VM address in its DRM-managed range, BO label and a GEM
state flags.
There's also a usage flags field for the type of BO, which tells us
whether it's a kernel BO and/or mapped onto the FW's address space.
GEM state and usage flag meanings are printed in the file prelude, so
that UM parsing tools can interpret the numerical values in the table.
Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Steven Price <steven.price@arm.com> Link: https://lore.kernel.org/r/20250423021238.1639175-5-adrian.larumbe@collabora.com Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Kernel BO's aren't exposed to UM, so labelling them is the responsibility
of the driver itself. This kind of tagging will prove useful in further
commits when want to expose these objects through DebugFS.
Expand panthor_kernel_bo_create() interface to take a NUL-terminated
string. No bounds checking is done because all label strings are given
as statically-allocated literals, but if a more complex kernel BO naming
scheme with explicit memory allocation and formatting was desired in the
future, this would have to change.
Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Reviewed-by: Steven Price <steven.price@arm.com> Link: https://lore.kernel.org/r/20250423021238.1639175-4-adrian.larumbe@collabora.com Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Add a new character string Panthor BO field, and a function that allows
setting it from within the driver.
Driver takes care of freeing the string when it's replaced or no longer
needed at object destruction time, but allocating it is the responsibility
of callers.
Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Reviewed-by: Steven Price <steven.price@arm.com> Link: https://lore.kernel.org/r/20250423021238.1639175-2-adrian.larumbe@collabora.com Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Matthew Auld [Wed, 16 Apr 2025 15:09:17 +0000 (16:09 +0100)]
drm/xe: handle pinned memory in PM notifier
Userspace is still alive and kicking at this point so actually moving
pinned stuff here is tricky. However, we can instead pre-allocate the
backup storage upfront from the notifier, such that we scoop up as much
as we can, and then leave the final .suspend() to do the actual copy (or
allocate anything that we missed). That way the bulk of our allocations
will hopefully be done outside the more restrictive .suspend().
We do need to be extra careful though, since the pinned handling can now
race with PM notifier, like something becoming unpinned after we prepare
it from the notifier.
v2 (Thomas):
- Fix kernel doc and drop the pin as soon as we are done with the
restore, instead of deferring to later.
Matthew Auld [Wed, 16 Apr 2025 15:09:16 +0000 (16:09 +0100)]
drm/xe: share bo dma-resv with backup object
We end up needing to grab both locks together anyway and keep them held
until we complete the copy or add the fence. Plus the backup_obj is
short lived and tied to the parent object, so seems reasonable to share
the same dma-resv. This will simplify the locking here, and in follow
up patches.
v2:
- Hold reference to the parent bo to be sure the shared dma-resv can't
go out of scope too soon. (Thomas)
Matthew Auld [Wed, 16 Apr 2025 15:09:15 +0000 (16:09 +0100)]
drm/xe: evict user memory in PM notifier
In the case of VRAM we might need to allocate large amounts of
GFP_KERNEL memory on suspend, however doing that directly in the driver
.suspend()/.prepare() callback is not advisable (no swap for example).
To improve on this we can instead hook up to the PM notifier framework
which is invoked at an earlier stage. We effectively call the evict
routine twice, where the notifier will have hopefully have cleared out
most if not everything by the time we call it a second time when
entering the .suspend() callback. For s4 we also get the added benefit
of allocating the system pages before the hibernation image size is
calculated, which looks more sensible.
Note that the .suspend() hook is still responsible for dealing with all
the pinned memory. Improving that is left to another patch.
John Harrison [Thu, 17 Apr 2025 21:33:03 +0000 (14:33 -0700)]
drm/xe/guc: Cache DSS info when creating capture register list
Calculating the DSS id (index of a steered register) currently
requires reading state from the hwconfig table and that currently
requires dynamically allocating memory. The GuC based register capture
(for dev core dumps) includes this index as part of the register name
in the dump. However, it was calculating said index at the time of the
dump for every dump. That is wasteful. It also breaks anyone trying to
do the dump at a time when memory allocations are not allowed.
So rather than calculating on every print, just calculate at start of
day when creating the register list in the first place.
John Harrison [Thu, 17 Apr 2025 19:52:13 +0000 (12:52 -0700)]
drm/xe/guc: Use the steering flag when printing registers
The printing code was doing a test on which list a register was in to
decide whether it is steered or not. That might be valid at this
moment but there may be other reasons for extended lists in the
future. Plus, there is a flag specifically for identifying steered
registers. So, just use that instead - it is simpler and safer.
John Harrison [Thu, 17 Apr 2025 19:52:12 +0000 (12:52 -0700)]
drm/xe/guc: Fix capture of steering registers
The list of registers to capture on a GPU hang includes some that
require steering. Unfortunately, the flag to say this was being wiped
to due a missing OR on the assignment of the next flag field.
Fix that.
Fixes: b170d696c1e2 ("drm/xe/guc: Add XE_LP steered register lists") Cc: Zhanjun Dong <zhanjun.dong@intel.com> Cc: Alan Previn <alan.previn.teres.alexis@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: "Thomas Hellström" <thomas.hellstrom@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: intel-xe@lists.freedesktop.org Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Zhanjun Dong <zhanjun.dong@intel.com> Link: https://lore.kernel.org/r/20250417195215.3002210-2-John.C.Harrison@Intel.com
drm/panel: make prepare/enable and disable/unprepare calls return void
Now there are no users of the return value of the drm_panel_prepare(),
drm_panel_unprepare(), drm_panel_enable() and drm_panel_disable() calls.
Usually these calls are performed from the atomic callbacks, where it is
impossible to return an error. Stop returning error codes and return
void instead.
drm/bridge: analogix_dp: ignore return values of drm_panel_* calls
Follow the example of other drivers and ignore return values of the
drm_panel_prepare() / unprepare() / enable() / disable() calls. There is
no possible error recovery, so the driver just logs a message.
The analogix_dp_prepare_panel() function is called from bridge's
atomic_pre_enable() and atomic_post_disable() callbacks, which can not
happen simultaneously. Drop the useless mutex.
drm/bridge: analogix_dp: drop unused argument to analogix_dp_prepare_panel()
After previous cleanup all calling sites pass true as is_modeset_prepare
argument to analogix_dp_prepare_panel(). Drop dead code depending on
that argument being false.
drm/bridge: analogix_dp: drop extra calls to analogix_dp_prepare_panel()
The analogix_dp_prepare_panel() returns immediately if there is no
attached panel. Drop several calls to this function which are performed
when dp->plat_data->panel is NULL.
Boris Brezillon [Thu, 17 Apr 2025 12:19:42 +0000 (14:19 +0200)]
drm/panthor: Don't create a file offset for NO_MMAP BOs
Right now the DRM_PANTHOR_BO_NO_MMAP flag is ignored by
panthor_ioctl_bo_mmap_offset(), meaning BOs with this flag set can
have a file offset but can't be mapped anyway, because
panthor_gem_mmap() will filter them out.
If we error out at mmap_offset creation time, we can get rid of
panthor_gem_mmap() and call drm_gem_shmem_object_mmap directly, and
we get rid of this inconsistency of having an mmap offset for a
BO that can never be mmap-ed.
Changes in v2:
- Get rid of panthor_gem_mmap()
- Get rid of the Fixes tag and adjust the commit message accordingly
- Return ENOPERM instead of EINVAL
Due to lack of a proper format specifier, %p4cc was being used instead
of %p4cl for the purpose of printing FourCCs. But the disadvange was
that they were being printed in a reverse order. %p4cl should correct
this issue.
Hector Martin [Tue, 8 Apr 2025 06:47:57 +0000 (12:17 +0530)]
lib/vsprintf: Add support for generic FourCCs by extending %p4cc
%p4cc is designed for DRM/V4L2 FourCCs with their specific quirks, but
it's useful to be able to print generic 4-character codes formatted as
an integer. Extend it to add format specifiers for printing generic
32-bit FourCCs with various endian semantics:
%p4ch Host byte order
%p4cn Network byte order
%p4cl Little-endian
%p4cb Big-endian
The endianness determines how bytes are interpreted as a u32, and the
FourCC is then always printed MSByte-first (this is the opposite of
V4L/DRM FourCCs). This covers most practical cases, e.g. %p4cn would
allow printing LSByte-first FourCCs stored in host endian order
(other than the hex form being in character order, not the integer
value).
Acked-by: Rasmus Villemoes <linux@rasmusvillemoes.dk> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Petr Mladek <pmladek@suse.com> Tested-by: Petr Mladek <pmladek@suse.com> Signed-off-by: Hector Martin <marcan@marcan.st> Signed-off-by: Aditya Garg <gargaditya08@live.com> Reviewed-by: Kees Cook <kees@kernel.org> Link: https://lore.kernel.org/r/PN3PR01MB9597B01823415CB7FCD3BC27B8B52@PN3PR01MB9597.INDPRD01.PROD.OUTLOOK.COM Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Damon Ding [Mon, 10 Mar 2025 10:41:12 +0000 (18:41 +0800)]
drm/rockchip: analogix_dp: Add support for RK3588
RK3588 integrates the Analogix eDP 1.3 TX controller IP and the HDMI/eDP
TX Combo PHY based on a Samsung IP block. There are also two independent
eDP display interface with different address on RK3588 Soc.
The patch currently adds only the basic support, specifically RGB output
up to 4K@60Hz, without the tests for audio, PSR and other eDP 1.3 specific
features.
In additon, the above Analogix IP has always been utilized as eDP on
Rockchip platform, despite its capability to also support the DP v1.2.
Therefore, the newly added logs will contain the term 'edp' rather than
'dp'. And the newly added 'apb' reset control is to ensure the APB bus
of eDP controller works well on the RK3588 SoC.
Damon Ding [Mon, 10 Mar 2025 10:41:10 +0000 (18:41 +0800)]
dt-bindings: display: rockchip: analogix-dp: Add support for RK3588
Compared with RK3288/RK3399, the HBR2 link rate support is the main
improvement of RK3588 eDP TX controller, and there are also two
independent eDP display interfaces on RK3588 Soc.
The newly added 'apb' reset is to ensure the APB bus of eDP controller
works well on the RK3588 SoC.
Damon Ding [Mon, 10 Mar 2025 10:41:09 +0000 (18:41 +0800)]
drm/rockchip: analogix_dp: Add support to get panel from the DP AUX bus
Move drm_of_find_panel_or_bridge() a little later and combine it with
component_add() into a new function rockchip_dp_link_panel(). The function
will serve as done_probing() callback of devm_of_dp_aux_populate_bus(),
aiding to support for obtaining the eDP panel via the DP AUX bus.
If failed to get the panel from the DP AUX bus, it will then try the other
way to get panel information through the platform bus.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Damon Ding <damon.ding@rock-chips.com> Reviewed-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20250310104114.2608063-9-damon.ding@rock-chips.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Damon Ding [Mon, 10 Mar 2025 10:41:07 +0000 (18:41 +0800)]
drm/bridge: analogix_dp: Add support to get panel from the DP AUX bus
The main modification is moving the DP AUX initialization from function
analogix_dp_bind() to analogix_dp_probe(). In order to get the EDID of
eDP panel during probing, it is also needed to advance PM operations to
ensure that eDP controller and phy are prepared for AUX transmission.
Signed-off-by: Damon Ding <damon.ding@rock-chips.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20250310104114.2608063-7-damon.ding@rock-chips.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Damon Ding [Mon, 10 Mar 2025 10:41:06 +0000 (18:41 +0800)]
drm/bridge: analogix_dp: Support to get &analogix_dp_device.plat_data and &analogix_dp_device.aux
Add two new functions: one to find &analogix_dp_device.plat_data via
&drm_dp_aux, and the other to get &analogix_dp_device.aux. Both of them
serve for the function of getting panel from DP AUX bus, which is why
they are included in a single commit.
Damon Ding [Mon, 10 Mar 2025 10:41:04 +0000 (18:41 +0800)]
drm/bridge: analogix_dp: Add support for phy configuration.
Add support to configurate link rate, lane count, voltage swing and
pre-emphasis with phy_configure(). It is helpful in application scenarios
where analogix controller is mixed with the phy of other vendors.
Damon Ding [Mon, 10 Mar 2025 10:41:03 +0000 (18:41 +0800)]
drm/bridge: analogix_dp: Remove CONFIG_PM related check in analogix_dp_bind()/analogix_dp_unbind()
Remove the check related to CONFIG_PM in order to make the code more
concise, as the CONFIG_PM should be a required option for many drivers.
In addition, it is preferable to use devm_pm_runtime_enable() instead of
manually invoking pm_runtime_enable() followed by pm_runtime_disable().
Suggested-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Damon Ding <damon.ding@rock-chips.com> Link: https://lore.kernel.org/r/20250310104114.2608063-3-damon.ding@rock-chips.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Damon Ding [Mon, 10 Mar 2025 10:41:02 +0000 (18:41 +0800)]
drm/bridge: analogix_dp: Add irq flag IRQF_NO_AUTOEN instead of calling disable_irq()
The IRQF_NO_AUTOEN can be used for the drivers that don't want
interrupts to be enabled automatically via devm_request_threaded_irq().
Using this flag can provide be more robust compared to the way of
calling disable_irq() after devm_request_threaded_irq() without the
IRQF_NO_AUTOEN flag.
Suggested-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Damon Ding <damon.ding@rock-chips.com> Link: https://lore.kernel.org/r/20250310104114.2608063-2-damon.ding@rock-chips.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Satyanarayana K V P <satyanarayana.k.v.p@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Michał Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://lore.kernel.org/r/20250403120641.7258-3-satyanarayana.k.v.p@intel.com
Signed-off-by: Satyanarayana K V P <satyanarayana.k.v.p@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Michał Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://lore.kernel.org/r/20250403120641.7258-2-satyanarayana.k.v.p@intel.com
Michal Wajdeczko [Mon, 14 Apr 2025 20:23:46 +0000 (22:23 +0200)]
drm/xe/guc: Fix out-of-bound while enabling engine activity stats
In the PF mode we allocate array of struct engine_activity_group
that holds activity data split for the PF and all potential VFs.
But while preparing data for use by VFs we ended with bad index.
drm/xe/pxp: do not queue unneeded terminations from debugfs
The PXP terminate debugfs currently unconditionally simulates a
termination, no matter what the HW status is. This is unneeded if PXP is
not in use and can cause errors if the HW init hasn't completed yet.
To solve these issues, we can simply limit the terminations to the cases
where PXP is fully initialized and in use.
v2: s/pxp_status/ready/ to avoid confusion with pxp->status (John)
Fixes: 385a8015b214 ("drm/xe/pxp: Add PXP debugfs support") Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/4749 Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: John Harrison <John.C.Harrison@Intel.com> Link: https://lore.kernel.org/r/20250416201622.1295369-1-daniele.ceraolospurio@intel.com
Alexander Baransky [Mon, 14 Apr 2025 17:26:32 +0000 (20:26 +0300)]
drm/panel: Add Visionox G2647FB105 panel driver
Add the driver for Visionox G2647FB105 6.47" FHD Plus CMD mode AMOLED panel
support found in:
- Xiaomi Mi Note 10 / CC9 Pro (sm7150-xiaomi-tucana)
- Xiaomi Mi Note 10 Lite (sm7150-xiaomi-toco)
Add a DT binding for the Visionox G2647FB105, a 6.47 inch 1080x2340
MIPI-DSI CMD mode AMOLED panel used in:
- Xiaomi Mi Note 10 / CC9 Pro (sm7150-xiaomi-tucana)
- Xiaomi Mi Note 10 Lite (sm7150-xiaomi-toco)
Xiaomi likes to use different panels in various revisions of the same
device. A factory panel even can be replaced with another model in a
service center.
So, the power configuration of this panel is similar to
some Samsung AMOLED panels, e.g. samsung,ams639rq08, which can be found on
other sm7150 Xiaomi devices. Even though Samsung panels weren't used
in sm7150-xiaomi-tucana and toco, the described voltage rails exist
(confirmed by schematics of the device).
AngeloGioacchino Del Regno [Mon, 14 Apr 2025 08:29:18 +0000 (10:29 +0200)]
drm: panel: Add driver for Himax HX8279 DDIC panels
Add a driver for the Himax HX8279-D MIPI-DSI DriverIC with support
for the Startek KX070FHFID078 7.0" 1200x1920 IPS panel, found on
various MediaTek Genio Evaluation Kit boards and for the Aoly
SL101PM1794FOG-v15 10.1" 1200x1920 LCD panel found on some I.MX8MM
boards.
Himax HX8279 is a Display DriverIC suitable for driving LCD
MIPI-DSI panels.
Describe this DriverIC, the Startek KD070FHFID078 panel found
on newer revisions of the MediaTek Genio 510/700/1200 Evaluation
Kits (EVK), and the Aoly SL101PM1794FOG-V15 found on some i.MX8MM
boards.
Reuse the timings of the TM070JDHG34-00 as they are identical, even though
they are described differently by the datasheet as noted in the
comment. Power up/down timing are slightly different, so add a new struct
panel_desc for that.
Boris Brezillon [Mon, 14 Apr 2025 13:01:20 +0000 (15:01 +0200)]
drm/panthor: Fix the panthor_gpu_coherency_init() error path
The panthor_gpu_coherency_init() call has been moved around, but the
error path hasn't been adjusted accordingly. Make sure we undo what
has been done before this call in case of failure.
Fixes: 7d5a3b22f5b5 ("drm/panthor: Call panthor_gpu_coherency_init() after PM resume()") Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Closes: https://lore.kernel.org/dri-devel/4da470aa-4f84-460e-aff8-dabc8cc4da15@stanley.mountain/T/#t Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://lore.kernel.org/r/20250414130120.581274-1-boris.brezillon@collabora.com Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
projects / users / jedix / linux-maple.git / log