| Age | Commit message (Collapse) | Author |
|---|
|
[WHY]
The RMCM logic was embedded inside the MPC block, sharing its source files,
functions, register definitions and other logic. This tight coupling
created several problems:
- The RMCM vtable was bolted onto struct mpc_funcs, making it impossible
to instantiate RMCM independently of MPC
- RMCM resource acquisition had no tracking - there was no mechanism to
allocate the 2 available RMCM instances to pipes or release them
[HOW]
RMCM is now a separate module:
- dc/rmcm/ directory with per-ASIC implementations
- new struct rmcm with its own funcs vtable containing shaper,
3DLUT, and fast-load operations
- removed all RMCM code from MPC
- added RMCM resource lifecycle management in dc_resource.c:
- resource_assign_rmcm(): Assigns the instances for a whole context, so a
plane that is only now asking never evicts one already using an instance
- resource_release_rmcm(): Clears the pipe's allocation.
- updated resource pool constructors (dcn42, dcn42b, dcn60) to create
RMCM instances via the new dcnXX_rmcm_create() and destroy them in
pool teardown
Reviewed-by: Sridevi Arvindekar <sridevi.arvindekar@amd.com>
Signed-off-by: Rafal Ostrowski <rafal.ostrowski@amd.com>
Signed-off-by: Chenyu Chen <chen-yu.chen@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
add energy accumulator on pmfw 0x00685000 and above version.
Signed-off-by: Kevin Wang <kevin.wang@amd.com>
Reviewed-by: Kenneth Feng <kenneth.feng@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Retire the legacy design, always enable unified MES on GFX 12.1 and drop
the driver code and MODULE_FIRMWARE entries that only served the legacy
path.
Signed-off-by: Horatio Zhang <hongkun.zhang@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
[Description]
- UPSP should only be enabled when we want linear scaling for 420/422
- In DC for non-FP16 formats that are told to scale in non-linear, program
bypass for PRE_GAM since these formats are already non-linear (i.e.,
YUV420, YUV422, RGB, etc.)
Reviewed-by: Aric Cyr <aric.cyr@amd.com>
Reviewed-by: Taimur Hassan <syed.hassan@amd.com>
Signed-off-by: Alvin Lee <Alvin.Lee2@amd.com>
Signed-off-by: Chenyu Chen <chen-yu.chen@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
[Why]
Hwss executors shouldn't be coupled to complex dc structs such as
pipe_ctx.
[How]
Refactor cursor offload hardware sequencer extension to accept only
the parameters required for programming cursor offload state.
Extract these parameters in the generic HWSS layer for both immediate execution
and block-sequence construction.
Reviewed-by: Ilya Bakoulin <ilya.bakoulin@amd.com>
Signed-off-by: Tomasz Siemek <tomasz.siemek@amd.com>
Signed-off-by: Chenyu Chen <chen-yu.chen@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Drop no longer valid tests and fix function signature.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
I got a null-ptr-deref report when closing a DRM file descriptor:
WARNING: drivers/gpu/drm/drm_atomic.c:2031 at
__drm_atomic_helper_set_config+0x18e/0x1b0 [drm]
Call Trace:
drm_client_modeset_commit_atomic+0x16b/0x220 [drm]
drm_client_modeset_commit_locked+0x56/0x160 [drm]
drm_client_modeset_commit+0x21/0x40 [drm]
__drm_fb_helper_restore_fbdev_mode_unlocked.part.0+0x7b/0x80
drm_fbdev_client_restore+0xe/0x20 [drm_client_lib]
drm_client_dev_restore+0x9f/0xc0 [drm]
drm_release+0xc5/0xe0 [drm]
The warning is followed by a NULL pointer dereference:
BUG: kernel NULL pointer dereference, address: 0000000000000008
RIP:
__drm_fb_helper_restore_fbdev_mode_unlocked.part.0+0x41/0x80
[drm_kms_helper]
Call Trace:
drm_fbdev_client_restore+0xe/0x20 [drm_client_lib]
drm_client_dev_restore+0x9f/0xc0 [drm]
drm_release+0xc5/0xe0 [drm]
__fput+0xdc/0x2b0
__x64_sys_close+0x39/0x80
do_syscall_64+0x8d/0x460
entry_SYSCALL_64_after_hwframe+0x76/0x7e
drm_client_register() adds the DRM client to the device client list
before invoking the initial hotplug callback. If the hotplug callback
fails, the client remains registered.
For the fbdev client, a failure during drm_fb_helper_initial_config()
causes the partially initialized fbdev helper to be cleaned up.
drm_fb_helper_fini() releases fb_helper->info and leaves it NULL.
The fbdev client therefore remains registered even though there is no
fully initialized framebuffer device.
Later, when userspace closes the DRM file descriptor, drm_release()
can invoke the restore callbacks of registered DRM clients:
drm_release()
drm_client_dev_restore()
drm_fbdev_client_restore()
drm_fb_helper_restore_fbdev_mode_unlocked()
drm_fbdev_client_restore() currently restores the fbdev state
unconditionally. For a partially initialized fbdev client this can
submit an incomplete modeset state and subsequently access fbdev
state which has not been initialized, resulting in the warning and
NULL pointer dereference above.
drm_fbdev_client_unregister() already uses fb_helper->info to
distinguish a fully probed framebuffer device from a partially
initialized client.
Use the same condition in drm_fbdev_client_restore() and skip restore
if no framebuffer device has been successfully initialized.
Signed-off-by: shechenglong <shechenglong@xfusion.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Fixes: 5d08c44e47b9 ("drm/fbdev: Add memory-agnostic fbdev client")
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Cc: <stable@vger.kernel.org> # v6.13+
Link: https://patch.msgid.link/20260907035147.1339-1-shechenglong@xfusion.com
|
|
Currently there's no indication if fence wait failed. Debug log about
it.
v2: Rebase, no timeout anymore
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/6b670a146bfcfd0cc2c7641cc8d72df96e356ef9.1789069102.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Continue early in the loop for no fence in order to reduce indent.
v2: Rebase
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/8ee588437fb214a20c57d8c181f28c57b81cacaa.1789069102.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
The struct intel_atomic_state * pointer variables and parameters are
named "state" everywhere. Follow suit in
intel_atomic_commit_fence_wait().
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/988f1253004e68d565f3915cbd24182ca95dee49.1789069102.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
i915 has the Kconfig option DRM_I915_FENCE_TIMEOUT, defaulting to 10
seconds. xe doesn't use it, instead defaulting to
MAX_SCHEDULE_TIMEOUT. Unify the behaviour by switching to
dma_fence_wait() which defaults to MAX_SCHEDULE_TIMEOUT.
As dma_fence_wait() returns 0 when the fence was signaled, update the
return value check.
This should be possible now that commit 3aef9c94c02b ("drm/i915: Perform
full wedge on display reset") has been merged, and we no longer rely on
the timeout.
v3: Try this again with full wedge
v2: Use dma_fence_wait(), fix return value check (Maarten)
Reviewed-by: Maarten Lankhorst <dev@lankhorst.se>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/1880e49c9270049d5dfd944a1cbf712d664d02aa.1789069102.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Analogous to what was added in Commit d41c79838c47 ("drm/panfrost:
Display list of device JM contexts over debugfs") for panfrost, add
similar debugfs information for panthor.
The group priority does not change over the lifetime of the group, so no
effort to synchronise with the scheduler lock is being made.
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Reviewed-by: Liviu Dudau <liviu.dudau@arm.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Link: https://patch.msgid.link/20260904-panthor-sched-group-prio-v3-1-678afcca08b8@collabora.com
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
|
|
https://gitlab.freedesktop.org/drm/msm into drm-fixes
Fixes for v7.3-rc4:
DT:
- Corrected indentation
Core:
- Marked fbdev as system memory
GPU:
- Fixed autosuspend cleanup on teardown
- a750: fix timestamps
- Increase GMU fw init timeout
- Misc fixes/cleanups
DPU:
- Fixed clock rounding, unbreaking newest platforms
- Cleared pending flush state
DP:
- Skip PUSH_IDLE when link was never enabled
- Fixed bandwidth checks
HDMI:
- Fixed runtime PM cleanup on probe failure
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Rob Clark <rob.clark@oss.qualcomm.com>
Link: https://patch.msgid.link/CACSVV021rZsjmiPEyR_LR7L=k7=DRV0QdsA50BF_Gd0s2DXaCw@mail.gmail.com
|
|
https://gitlab.freedesktop.org/drm/amdgpu/kernel into drm-next
amd-drm-next-7.4-2026-09-10:
amdgpu:
- Freesync fixes
- GPUVM fix
- Debugfs fixes
- HDMI updates
- IPS fix
- GPU reset fix
- RGB quantization fixes
- SMU 13.0.x fixes
- MES updates
- UserQ updates
- UVD fix
- Various bounds checks
- DML fixes
- DCN 6 updates
- NBIO 7.11.5 support
- Audio fixes
- More display KUnit tests
- SMU 15 updates
- RAS updates
- VCN 5.0.2 updates
- JPEG 5.0.2 updates
- DCN 4.2 updates
- PSR fixes
- Misc cleanups
- PSP 15.0.8 updates
- RAS BERT support
- RAS CPER updates
- vblank fixes
- LSDMA updates
- GC 12.1 updates
- MMHUB 4.2 updates
- NBIO 6.3.2 updates
- SMU 15.0.8 updates
- IP discovery updates
- GPU spatial partitioning updates
- HDMI 2.1 freesync support
- HDMI 2.1 ALLM support
- HDMI 2.1 VRR support
- Require jobs for IBs
- Enable FRL for HDMI
- MES oversubscription fixes
- IH 6-7 updates
- GMC 11-12 fault handling updates
- Fixed point cleanup
- Backlight fixes
- GPUVM cleanup
- Devcoredump fixes
- UALoE (UALink over Ethernet) Support
- SDMA userq fixes
- GC 8 fix
amdkfd:
- Various bounds checks
- SVM fixes
- GC 12.1 updates
- MES updates
- Trap handler fixes
- Debugfs fixes
drm:
- Add gem callback for when handle count goes to 0
- Rust fix
UAPI:
- INFO IOCTL fix for 32 bit userspace on 64 bit kernel
- Add syncobj_points to USERQ signal ioctl
Proposed userspace:
* radeonsi NV_timeline_semaphore
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37335
* RADV user queues
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40808
- Add UALink support IOCTLs
Proposed userspace:
https://github.com/ROCm/rocm-systems/blob/35959f8e1260c7cee3e51a740e320be3856ee4ff/projects/rocr-runtime/libhsakmt/src/memory.c#L971
https://github.com/ROCm/rocm-systems/blob/35959f8e1260c7cee3e51a740e320be3856ee4ff/projects/rocr-runtime/libhsakmt/src/memory.c#L1036
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Alex Deucher <alexander.deucher@amd.com>
Link: https://patch.msgid.link/20260910213040.826425-1-alexander.deucher@amd.com
|
|
i915_gem_busy_ioctl uses dma_resv_for_each_fence_unlocked() to iterate
over the fences in an GEM object without holding a reference but only
the RCU read side lock.
What can happen here is that the GEM object is destroyed concurrently
while i915_gem_busy_ioctl is still running. This won't free the GEM
objects memory, but still drops all the dma_fence references.
Now when dma_resv_for_each_fence_unlocked() sees a destroyed dma_fence it
assumes that a new fence list was installed and re-starts the loop.
But in the case of a destroyed GEM object a new fence list is never
installed, only the old one freed and therefore the iteration never
finishes resulting in an endless loop.
The solution is to drop the fence references only after the RCU grace
period.
The fixes tag is not necessary the patch introducing the problem, but the
one making it so worse that we need to address it.
This problem was pointed out by Sashiko-bot.
Signed-off-by: Christian König <christian.koenig@amd.com>
Fixes: 912ff2ebd695 ("drm/i915: use the new iterator in i915_gem_busy_ioctl v2")
CC: stable@vger.kernel.org
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net>
Link: https://lore.kernel.org/r/20260903113621.54660-1-christian.koenig@amd.com
|
|
Fix dependency of the panic-helper KUnit tests on CONFIG_DRM_KUNIT_TEST=y
and make them build as a module. Export the necessary interfaces from the
panic helpers iff the KUnit framework has been enabled.
Select DRM_PANIC_HELPER from DRM_KUNIT_TEST to meet the dependencies of
the panic-helper tests.
It is now possible to run the tests by modprobe-ing drm_panic_helper_test
at runtime.
v5:
- clear test description with drm_panic_helper_clear_description() (Sashiko)
v3:
- clean up after each test case (Sashiko)
v2:
- fix parameter order in decl of drm_panic_helper_draw_screen_qr()
(Sashiko)
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://patch.msgid.link/20260911124540.279841-15-tzimmermann@suse.de
|
|
Move drm_plane_helper_display_panic_screen() and the existing panic-
display code into drm_panic_helper.c. Rename symbols accordingly.
Also update the QR-related code and the bindings accordingly.
Link the rsp. object file into drm_kms_helper.ko. Eventually the code
will become a DRM drawing library, together with DRM's format and draw
helpers. This requires more preparation. until then, KMS helpers serve
as a module. All DRM drivers link it anyway.
Add a new section about drawing helpers to the documentation of the KMS
helpers. List format and panic helpers there.
v2:
- fix dependencies on other DRM modules (Randy, Sashiko)
- provide placeholders for drm_panic_helper_{init,exit}() (Sashiko)
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://patch.msgid.link/20260911124540.279841-14-tzimmermann@suse.de
|
|
None of the DRM drivers handles panic locking. Declare the interfaces
in an internal header file. Move the trylock required during the panic
into the DRM core's sources.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://patch.msgid.link/20260911124540.279841-13-tzimmermann@suse.de
|
|
Add display_panic_screen to struct drm_plane_funcs. If set on a plane,
register a panic handler for the plane from the DRM core's panic
handling. Invoke this helper from the core to display a panic screen.
The new callback replaces get_scanout_buffer as signal for panic
support in a plane. Using get_scanout_buffer is now merely a detail
of the implementation. This will also free struct drm_scanout_buffer
for use cases besides panic handling.
With display_panic_screen in place, rename draw_panic_plane() to
drm_plane_helper_display_panic_screen() and make it available to DRM
drivers via drm_panic_helper.h. Do not change the implementation or
functionality of this code. drm_plane_helper_display_panic_screen()
still supports kernel messages, user messages and QR codes on various
color formats.
Then update all drivers that implement panic support. Provide the
initializer macro DRM_PANIC_PLANE_FUNCS that sets display_panic_screen
to drm_plane_helper_display_panic_screen(). If panic handling has
been disabled, it instead clears the callback. There's again no change
in functionality.
This logically splits panic handling into a set of entry points in the
DRM code and a set of helper functions provided by drivers. The core
invokes the driver's helper via callback, while the driver can tailor
the implementation to its needs. Panic handling now works like most
other interfaces in the DRM framework.
Locking and state-handling happens in the DRM core or helpers. Drivers
that receive a call to display_panic_screen can assume that no concurrent
modeset takes place on the plane or its CRTC.
Also update the documentation. Move information about locking and state
guarantees from drm_panic_trylock() to display_panic_screen, where
drivers authors can find it easily. Move information about the features
of the current implementation to drm_panic_helper_display_panic_screen().
v4:
- remove obsolete comment about fbcon interference (Jocelyn)
v2:
- only consider planes with get_scanout_buffer (Sashiko)
- set callback for planes create with drm_crtc_init() (Sashiko)
- return errno code from display_panic_screen
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://patch.msgid.link/20260911124540.279841-12-tzimmermann@suse.de
|
|
Restrict panic handling to primary displays. Overlays and cursors
should not display panic output. If there are exceptions, they can
be registered by the driver itself.
v3:
- also update drm_panic_is_enabled() (Sashiko)
- still do some testing when unregistering (Sashiko)
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://patch.msgid.link/20260911124540.279841-11-tzimmermann@suse.de
|
|
Move locking and parameters from draw_panic_plane() into the new
helper drm_panic_display_panic_screen(). Call draw_panic_plane() from
there.
The new helper drm_panic_display_panic_screen() is now the DRM core's
interface for displaying a panic screen. The code remaining in
draw_panic_plane() still does all the heavy lifting. It will become a
plane helper for DRM drivers.
v2:
- use panic_type argument in draw_panic_plane() (Sashiko)
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://patch.msgid.link/20260911124540.279841-10-tzimmermann@suse.de
|
|
On failed output of QR codes and kmsg buffers, fall back to a user
message. QR-code output already did this internally, but now formally
support it in drm_panic_dispatch(). Streamlines the existing logic.
With the implicit fallback removed from QR-code support, the tests
cases fail for thr smallest output size (300x200). This is because the
QR code requires a minimal output size. Increase the size to 494x494,
which is the minimum supported size for QR output.
v3:
- update outdated commit description (Sashiko)
v2:
- fix minimum test size (Sashiko)
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://patch.msgid.link/20260911124540.279841-9-tzimmermann@suse.de
|
|
Return an error if the display is too small to display at least a
single character. If the panic handler cannot display any message
it does at least not destroy the current output, which might help
with identifying the problem.
v4:
- also check font height against scanout buffer (Jocelyn)
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://patch.msgid.link/20260911124540.279841-8-tzimmermann@suse.de
|
|
Set the panic type and QR version in draw_panic_plane() as a single
point of truth. Pass the values into the individual drawing functions.
In the test case, always create a QR code with version 40 (i.e., the
highest supported version).
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://patch.msgid.link/20260911124540.279841-7-tzimmermann@suse.de
|
|
Set the panic-screen colors in draw_panic_plane() as a single point
of truth. Pass the values into the individual drawing functions.
In the test cases, replace the Kconfig-defined colors with white and
black. Allows for removal of the tests' limitations and dependency on
the exact values. All tests now always verify the generated output.
Hardcoding the test colors will later also allow for building the
test case without having DRM panic handling enabled.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://patch.msgid.link/20260911124540.279841-6-tzimmermann@suse.de
|
|
Return errno codes from the panic output helpers to detect invalid
panic handling. Avoid flushing the display if an error ocured. The
unflushed display output might be helpful in debugging.
For now, test the result values in the panic test cases. A later patch
will add support for retrying failed panic output.
v2:
- forward return value of draw_panic_screen_user() (Sashiko)
- forward errno code from drm_panic_get_qr_code
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://patch.msgid.link/20260911124540.279841-5-tzimmermann@suse.de
|
|
Font lookup does not allocate memory. Hence reporting ENOMEM on
failed lookups is misleading. Report EINVAL instead.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://patch.msgid.link/20260911124540.279841-4-tzimmermann@suse.de
|
|
Do nothing if kmap_local_page_try_from_panic() returns NULL. This is
not likely to hapen, as the previous page from the same memory area
has been mapped successfully.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Fixes: 23437509a694 ("drm/panic: Fix 24bit pixel crossing page boundaries")
Cc: Javier Martinez Canillas <javierm@redhat.com>
Cc: Jocelyn Falempe <jfalempe@redhat.com>
Cc: dri-devel@lists.freedesktop.org
Cc: <stable@vger.kernel.org> # v6.18+
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://patch.msgid.link/20260911124540.279841-3-tzimmermann@suse.de
|
|
Replace the direct use of DRM_PANIC_SCREEN_QR_CODE_URL in snprintf()
with a %s conversion specifier. Avoids a possible vulnerabilty from
a crafted URL string.
As the attacker needs to control the kernel at the Kconfig level, the
potential for an exploit is likely low.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Fixes: cb5164ac43d0 ("drm/panic: Add a QR code panic screen")
Cc: Javier Martinez Canillas <javierm@redhat.com>
Cc: Jocelyn Falempe <jfalempe@redhat.com>
Cc: dri-devel@lists.freedesktop.org
Cc: <stable@vger.kernel.org> # v6.12+
Link: https://patch.msgid.link/20260911124540.279841-2-tzimmermann@suse.de
|
|
After commit 860e748bddcc929 ("drm: ensure blend mode supported if pixel
format with alpha exposed") we get warnings at boot:
loongson 0000:00:06.1: [drm] [PLANE:41:ls-cursor-plane-0] pixel format with alpha exposed but blend mode not setup. Please fix.
loongson 0000:00:06.1: [drm] [PLANE:46:ls-cursor-plane-1] pixel format with alpha exposed but blend mode not setup. Please fix.
The reason is the cursor plane supports color formats with alpha but the
driver doesn't create blend mode property, which triggers the warning in
validate_blend_mode_for_alpha_formats().
The loongson DC HW doesn't support DRM_MODE_BLEND_PREMULTI, so create
blend mode property with DRM_MODE_BLEND_COVERAGE for cursor planes since
it is the only one implemented in the driver.
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
Reviewed-by: Jianmin Lv <lvjianmin@loongson.cn>
Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
Link: https://patch.msgid.link/20260903084212.3621540-1-chenhuacai@loongson.cn
|
|
Its observed that on AUX_CH failure, even if the retry is increased to
1000, it does not succeed. Either the command might be wrong or sink in
an unknown/sleep state can cause this. So try waking the sink device.
Before reading the DPCD caps wake the sink for eDP.
v2: Use poll_timeout_us (Jani N)
Add the reason, why this change is required (Ville)
v3: Wake sink only for eDP
Remove the dpcd probe set to true/false in wake_sink (Imre)
v4: make edp_wake_sinc() static and dpcd_readb -> dpcd_reab_byte (Suraj)
v5: Drop poll_timeout_us. drm_dp_dpcd_read_byte() already retries the AUX
transaction internally (up to ~16ms), so the outer 6ms poll could
never iterate and only added a pre-read delay on the hot path; read
DP_SET_POWER once instead. Wake the sink before reading the DPCD
caps, otherwise a sleeping sink fails the caps read and returns
early before the wake ever runs. (Suraj, Jani, Sashiko)
v6: Mask and write DP_SET_POWER (Sashiko)
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/4391
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/16654
Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260915042300.2201757-1-arun.r.murthy@intel.com
|
|
All plane drivers now implement the atomic_create_state hook instead of
the reset hook for initial state creation. The reset hook conflated
initial state allocation at probe time with hardware and software reset
during suspend/resume, making error handling difficult since it is not
fallible.
Remove the reset hook from struct drm_plane_funcs and the associated
call in drm_mode_config_reset().
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patch.msgid.link/20260916-drm-no-more-plane-reset-v5-9-f590d2003f2c@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
|
|
__drm_atomic_helper_plane_reset() is no longer used: all callers now go
through __drm_atomic_helper_plane_state_init(). Remove it.
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patch.msgid.link/20260916-drm-no-more-plane-reset-v5-8-f590d2003f2c@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
|
|
drm_atomic_helper_plane_reset() is no longer used: all callers now go
through drm_atomic_helper_plane_create_state(). Remove it.
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patch.msgid.link/20260916-drm-no-more-plane-reset-v5-7-f590d2003f2c@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
|
|
The xen plane implementation uses the deprecated
drm_atomic_helper_plane_reset() as its reset hook.
Switch to drm_atomic_helper_plane_create_state() instead.
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patch.msgid.link/20260916-drm-no-more-plane-reset-v5-6-f590d2003f2c@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
|
|
The tve200 plane implementation uses the deprecated
drm_atomic_helper_plane_reset() as its reset hook.
Switch to drm_atomic_helper_plane_create_state() instead.
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patch.msgid.link/20260916-drm-no-more-plane-reset-v5-5-f590d2003f2c@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
|
|
The pl111 plane implementation uses the deprecated
drm_atomic_helper_plane_reset() as its reset hook.
Switch to drm_atomic_helper_plane_create_state() instead.
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patch.msgid.link/20260916-drm-no-more-plane-reset-v5-4-f590d2003f2c@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
|
|
The mcde plane implementation uses the deprecated
drm_atomic_helper_plane_reset() as its reset hook.
Switch to drm_atomic_helper_plane_create_state() instead.
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patch.msgid.link/20260916-drm-no-more-plane-reset-v5-3-f590d2003f2c@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
|
|
The aspeed plane implementation uses the deprecated
drm_atomic_helper_plane_reset() as its reset hook.
Switch to drm_atomic_helper_plane_create_state() instead.
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patch.msgid.link/20260916-drm-no-more-plane-reset-v5-2-f590d2003f2c@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
|
|
The arcgpu plane implementation uses the deprecated
drm_atomic_helper_plane_reset() as its reset hook.
Switch to drm_atomic_helper_plane_create_state() instead.
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patch.msgid.link/20260916-drm-no-more-plane-reset-v5-1-f590d2003f2c@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
|
|
In supported devices, HPDs can generate PME and which in turn
can invoke runtime resume calls for xe. No need to keep the
HPD polling in such PME capable devices.
v2: use intel_display_rpm_pme_enabled() directly (JaniN)
Bspec: 52979, 52980, 68857, 68867, 68970
Assisted-by: GitHub_Copilot:claude-opus-5
Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://patch.msgid.link/20260915092518.639448-6-vinod.govindapillai@intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
|
If a device supports generating PME from HPDs, resetting HPD IRQs
will be counter productive as HPDs itself will be lost. During
suspend routines, all the IRQs are reset. So if the device is
capable of generating PME rom HPDs, keep the HPD related IRQs from
reset based on the PME capability of the device on a target power
state. PME capability will be assessed and updated separately.
v2: change keep_hpd to reset_hpd
v3: use intel_display_rpm_pme_enabled() directly (JaniN)
v4: remove the unused include file from the previous revision
Bspec: 52979, 52980, 68857, 68867, 68970
Assisted-by: GitHub_Copilot:claude-opus-5
Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://patch.msgid.link/20260915092518.639448-5-vinod.govindapillai@intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
|
Plug the pme_enabled query for xe. It will return the current
PME status for the device. For supported platforms, PME is
enabled during runtime suspend calls if the device is PME is capable.
v2: use the xe_pm_pme_enabled()
Assisted-by: GitHub_Copilot:claude-opus-5
Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://patch.msgid.link/20260915092518.639448-4-vinod.govindapillai@intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
|
PME capabiliy need to be assessed very early during runtime suspend
routine to avoid resetting HPDs during IRQ resets. As display
runtime pm routines are being executed in the independent intel
display driver entry points, we need to have independent access
to the pme status as well. Add a provision to query the optional
pme_enabled to the parent interface so that it could be called
independently based on xe/i915's pme_enabled() implementation.
Assisted-by: GitHub_Copilot:claude-opus-5
Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://patch.msgid.link/20260915092518.639448-3-vinod.govindapillai@intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
|
Introduce PME support for PME capable devices. Whether device is
PME capable is assessed during PCI probe routine. And the whether
PME is enabled for a specific context is assessed during the PM
runtime suspend call if the device is PME capable.
If the PME is enabled, HPDs can generate PME which in turn call
the runtime resume call and do the wakeup routines. Till now
the driver was relying on HPD polling to wakeup in case of any
HPDs. HPD polling can be avoided in platforms with PME support
and instead rely on this PCI PME for HPD induced wakeup.
v2: access functions for xe.pme.enabled status and clear the pme.
enabled in case of error in xe_pm_runtime_suspend()
v3: use the local pme_enabled flag to clear the device wakeup
incase of error
v4: call the devm_device_init_wakeup() only if device is PME
capable to avoid false wakeup capable reporting in platforms
where PME is not supported.
Squash the patch which handled the lockdep deadlock handling
Bspec: 52979, 52980, 68857, 68867, 68970
Assisted-by: GitHub_Copilot:claude-opus-5
Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://patch.msgid.link/20260915092518.639448-2-vinod.govindapillai@intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
|
Currently, struct xe_i2c is freed before SGUnit IRQ is disabled in unbind
path, leaving a potential UAF in case I2C IRQ is hit during this small
window. Explicitly disable I2C IRQ in xe_i2c_remove() and fix this.
Fixes: 0bb78ce09926 ("drm/xe/i2c: Wire up reset/postinstall for I2C IRQ")
Signed-off-by: Raag Jadav <raag.jadav@intel.com>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://patch.msgid.link/20260911121547.2407261-1-raag.jadav@intel.com
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
(cherry picked from commit 8ba5c8b8ab3fd362267c11df2cd5a90ee46f6e24)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
|
Add region 5 (System Controller) to the list of regions
available on device.
Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patch.msgid.link/20260914-nvm_add_sysctl_region-v1-1-75d710daf5d0@intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
|
Use EXPORT_SYMBOL_IF_KUNIT() instead of the regular EXPORT_SYMBOL() to
export the symbols to the kunit namespace. Otherwise, the symbols get
exported for all the kernel to see, and the corresponding
MODULE_IMPORT_NS("EXPORTED_FOR_KUNIT_TESTING") in the tests is
meaningless.
Fixes: 2eb9982ff179 ("drm/i915/kunit: Export link training and caps funcs for testing")
Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260915160620.779372-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
During an atomic commit after all the MST stream CRTC state is computed
the driver ensures that the sum of TUs of all the streams on a given MST
topology link is within limits (63 for 8b10 and 64 for 128b132b). For a
disconnected stream the DRM MST core's BW verification doesn't ensure
this, because the topology state it uses for this is destroyed as soon
as the stream (i.e. MST connector/port) is disconnected. The driver
should keep the link state valid even for such disconnected streams, as
userspace may disable them one-by-one only in a deferred way. Ensure the
link's sum of TUs stays within limits in this case by simply reusing the
maximum link BPP limit from the stream's (i.e. CRTC's) old state.
The disconnection can happen either via the whole topology getting
disconnected or via only the given stream's port getting disconnected.
Check for both of these conditions separately, as a connector gets
unregistered after a link disconnect event only in a deferred way.
Cc: stable@vger.kernel.org # v6.10+
Link: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/16073
Link: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/16384
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260907174413.741851-2-imre.deak@intel.com
|
|
During an atomic commit after all the MST stream CRTC state is computed
the driver ensures that the FEC is configured the same way (enabled or
disabled) for all the streams on a given MST topology's link.
drm_dp_mst_port_downstream_of_parent() used to determine if a stream is
downstream of an MST port will return false if the whole topology is
disconnected, since in that case it can't verify that the port/
parent_port passed to it is in the given MST topology. This is a problem
during the above FEC configuration check, since
intel_dp_mst_check_dsc_change()->get_pipes_downstream_of_mst_ports()
will not return all the stream CRTCs/pipes for the topology as expected.
Since passing parent_port==NULL to get_pipes_downstream_of_mst_port()
is meant to return all the streams for the given topology (i.e. mst_mgr)
skip checking if an MST port is downstream of a parent port in this
case.
This fixes a problem where the FEC configuration check explained above
failed to ensure that all streams' FEC is configured the same way if the
topology was disconnected, leading to a FEC state mismatch error.
Cc: stable@vger.kernel.org # v6.10+
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/16073
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/16384
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260907174413.741851-1-imre.deak@intel.com
|
