kernel/git/next/linux-next.git/drivers/gpu/drm/ast, branch master

Merge branch 'for-linux-next' of https://gitlab.freedesktop.org/drm/misc/kernel.git

2026-09-18T12:17:04+00:00

Merge branch 'drm-next' of https://gitlab.freedesktop.org/drm/kernel.git

2026-09-18T11:13:54+00:00

# Conflicts: # drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c # drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c # drivers/gpu/drm/nouveau/nouveau_connector.c # drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r570/fbsr.c # drivers/gpu/drm/xe/xe_pagefault.c

drm/panic: Display panic screen via per-plane callback

2026-09-17T07:16:31+00:00

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 Reviewed-by: Jocelyn Falempe Link: https://patch.msgid.link/20260911124540.279841-12-tzimmermann@suse.de

drm/ast: create blend mode property on cursor plane

2026-09-08T13:12:26+00:00

Since commit 860e748bddcc ("drm: ensure blend mode supported if pixel format with alpha exposed"), drm_mode_config_validate() warns when a plane exposes an alpha pixel format but not the "pixel blend mode" property. The ast cursor plane (ARGB4444, ARGB8888) trips this on driver load: [PLANE:37:plane-1] pixel format with alpha exposed but blend mode not setup WARNING: drivers/gpu/drm/drm_mode_config.c:872 at drm_mode_config_validate+0x48f/0x510 [drm] ... Call Trace: drm_dev_register+0x1ce/0x290 [drm] ast_pci_probe+0x19d/0x3f0 [ast] local_pci_probe+0x41/0x90 Per Thomas Zimmermann's review, the ASPEED documentation describes the hardware cursor as blending with straight (non-pre-multiplied) alpha, which corresponds to DRM_MODE_BLEND_COVERAGE. Expose a "pixel blend mode" property advertising only DRM_MODE_BLEND_COVERAGE to make the hardware semantics explicit and silence the warning. Fixes: 860e748bddcc ("drm: ensure blend mode supported if pixel format with alpha exposed") Suggested-by: Thomas Zimmermann Reviewed-by: Thomas Zimmermann Tested-by: Thomas Zimmermann Signed-off-by: Qinyun Tan Signed-off-by: Thomas Zimmermann Link: https://patch.msgid.link/20260901083234.1828755-2-qinyuntan@linux.alibaba.com

drm/ast: Convert to atomic_create_state

2026-08-31T13:11:18+00:00

The ast crtc implementation provides a custom reset hook. However, this hook only allocates the state, initializes it with __drm_atomic_helper_crtc_reset(), and frees the previous state. It does not perform any hardware reset. Since this is exactly what the atomic_create_state hook is meant to do, minus the old state cleanup which the caller handles, convert the implementation to use atomic_create_state with __drm_atomic_helper_crtc_state_init() instead. Reviewed-by: Thomas Zimmermann Link: https://patch.msgid.link/20260821-drm-no-more-crtc-reset-v1-47-fb793475c05a@kernel.org Signed-off-by: Maxime Ripard

drm/ast: DisplayPort edid supports 256 bytes

2026-08-31T10:49:11+00:00

DisplayPort supports EDID up to 256 bytes (blocks 0 and 1). Update the block check to allow these two blocks. For any block beyond that (i.e. the monitor's EDID is larger than the 256 bytes ASPEED DP can hold), report it as an all-zero block instead of a read failure. Also remove the manual checksum/extension-count patch of block 0's last four bytes. That code was already dead, so the condition can never be true. Signed-off-by: Jammy Huang Reviewed-by: Thomas Zimmermann Signed-off-by: Thomas Zimmermann Link: https://patch.msgid.link/20260819-upstream_ast_dp_edid-v3-1-15d36c28afe2@aspeedtech.com

Merge tag 'drm-misc-next-2026-04-20' of https://gitlab.freedesktop.org/drm/misc/kernel into drm-next

2026-05-06T00:12:25+00:00

drm-misc-next for v7.1-rc1: UAPI Changes: - Expose per-client BO memory usage via fdinfo in amdxdna. (Hou) - Change the default priority of drm scheduler to fair. (Tvrtko) Cross-subsystem Changes: - Revert hugetlb support in udmabuf. (Gunthorpe) - Fix error in udmabuf with CONFIG_DMA_API_DEBUG(/ _SG). (Gavrilov) - Add Docbook for DRM_IOCTL_SYNCOBJ_EVENTFD, (Ser) clarify drm_bridge_get/put. (Tvrtko) - Change signature of drm_connector_attach_hdr_output_metadata_property. (Canal) - Use IOVA allocations in gpusvm and pagemap APIs. (Brost) - Fix tracepoints vs dma-fence lifetime. (Tvrtko) - Convert st-dma*.c tests to use kunit. (Gunthorpe) Core Changes: - Deduplicate counter and timestamp retrieval in vblank code. (Ville) - Parse AMD VSDB v3 in CTA extension blocks, and use it in amdgpu. (Chen) - Prevent bridge and encoder chain changes at inopportune times. (Ceresoli) - Map the run queue 1:1 to the drm scheduler. (Tvrtko) Driver Changes: - Assorted bugfixes and (documentation) updates to rockchip, bridge/synopsis, panfrost, tidss, accel/qaic, tilcdc, vc4, ast, imagination, panthor, renesas, accel/amdxdna, msxfb, bridge/imx8mp, nouveau. bridge/analogix_dp, bridge/exynos_dp, omap. - Add support for CSW PNB601LS1-2, LGD LP116WHA-SPB1, panels. - Add support for a lot of waveshare panels (Baryshkov) - Support for AIE4 devices in accel/wamdxdna. (Zhang) - Enable support for GEM shrinking in panthor. (Goel/Brezillon) - Runtime Power Management is added to v3d. (Canal) - Allow panel probing and use the panel bridge helper in analogix_dp. (Ding) - Support XRGB1555 and C8 in mgag and XRGB1555 in ast. (Zimmermann) From: Maarten Lankhorst Link: https://patch.msgid.link/bf31b1a1-951b-4f60-b226-22e8c083697d@linux.intel.com Signed-off-by: Dave Airlie

drm: Rename struct drm_atomic_state to drm_atomic_commit

2026-05-04T04:05:04+00:00

The KMS framework uses two slightly different definitions for the state concept. For a given object (plane, CRTC, encoder, etc., so drm_$OBJECT_state), the state is the entire state of that object. However, at the device level, drm_atomic_state refers to a state update for a limited number of objects. Thus, drm_atomic_state isn't the entire device state, but only the full state of some objects in that device. This has been an endless source of confusion and thus bugs. We can rename the drm_atomic_state structure to drm_atomic_commit to make it less confusing. This patch was created using: rg -l drm_atomic_state | \ xargs sed -i 's/drm_atomic_state/drm_atomic_commit/g; s/drm_atomic_commit_helper/drm_atomic_state_helper/g' mv drivers/gpu/drm/tests/drm_atomic_state_test.c drivers/gpu/drm/tests/drm_atomic_commit_test.c Acked-by: Simona Vetter Acked-by: Thomas Zimmermann Acked-by: Jani Nikula Reviewed-by: Luca Ceresoli Tested-by: Luca Ceresoli Signed-off-by: Maxime Ripard Signed-off-by: Dave Airlie Link: https://patch.msgid.link/20260427-drm-drm-atomic-update-v4-1-c0e713bfdf25@kernel.org

drm/ast: Support DRM_FORMAT_XRGB1555 on the primary plane

2026-04-20T07:12:01+00:00

Export DRM_FORMAT_XRGB1555 in the primary plane's format array and handle the format in the color-format updates. With this, ast is now feature complete wrt. color-format support. Also update the comments in the gamma-LUT code to reflect the ast manual's terminology. Signed-off-by: Thomas Zimmermann Reviewed-by: Jocelyn Falempe Link: https://patch.msgid.link/20260414070522.33943-5-tzimmermann@suse.de

drm/ast: Replace references to struct drm_format_info.cpp

2026-04-20T07:12:00+00:00

Replace all uses of struct drm_format_info.cpp with the corresponding 4CC constant. Color-mode selection uses switch statements that branch by cpp in several places. While at it, also name the involved variables according to register names and replace magic values with constants. Replace the use of *ModeIndex constants in ast_set_vbios_color_reg() with correct register constants. The former are array indices and do not belong into registers. In ast_set_color_reg(), vgacra0 is independent from the color format, so move it out from the switch statements. There is also a flag for gamma correction in vgacra8, which currently ast_set_color_reg() handles as part of the primary plane. The gamma LUT and its programming is located in the CRTC. A future update should consolidate gamma correction in the primary plane and implement the functionality with DRM's colorop helpers. Signed-off-by: Thomas Zimmermann Reviewed-by: Jocelyn Falempe Link: https://patch.msgid.link/20260414070522.33943-4-tzimmermann@suse.de