History log of /linux-6.15/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c (Results 1 – 25 of 57)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: v6.15, v6.15-rc7, v6.15-rc6, v6.15-rc5, v6.15-rc4, v6.15-rc3, v6.15-rc2, v6.15-rc1, v6.14, v6.14-rc7, v6.14-rc6, v6.14-rc5, v6.14-rc4, v6.14-rc3
# df1e82e7 13-Feb-2025 David Rosca <[email protected]>

drm/amdgpu/display: Allow DCC for video formats on GFX12

We advertise DCC as supported for NV12/P010 formats on GFX12,
but it would fail on this check on atomic commit.

Signed-off-by: David Rosca <

drm/amdgpu/display: Allow DCC for video formats on GFX12

We advertise DCC as supported for NV12/P010 formats on GFX12,
but it would fail on this check on atomic commit.

Signed-off-by: David Rosca <[email protected]>
Reviewed-by: Ruijing Dong <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
(cherry picked from commit ba795235a2b99ba9bbef647ab003b2f3145d9bbb)
Cc: [email protected] # 6.12.x

show more ...


# 3855f1d9 07-Mar-2025 Marek Olšák <[email protected]>

drm/amd/display: allow 256B DCC max compressed block sizes on gfx12

The hw supports it.

Signed-off-by: Marek Olšák <[email protected]>
Acked-by: Alex Deucher <[email protected]>
Signed-of

drm/amd/display: allow 256B DCC max compressed block sizes on gfx12

The hw supports it.

Signed-off-by: Marek Olšák <[email protected]>
Acked-by: Alex Deucher <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>

show more ...


# ba795235 13-Feb-2025 David Rosca <[email protected]>

drm/amdgpu/display: Allow DCC for video formats on GFX12

We advertise DCC as supported for NV12/P010 formats on GFX12,
but it would fail on this check on atomic commit.

Signed-off-by: David Rosca <

drm/amdgpu/display: Allow DCC for video formats on GFX12

We advertise DCC as supported for NV12/P010 formats on GFX12,
but it would fail on this check on atomic commit.

Signed-off-by: David Rosca <[email protected]>
Reviewed-by: Ruijing Dong <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>

show more ...


Revision tags: v6.14-rc2
# c905aa68 04-Feb-2025 Rodrigo Siqueira <[email protected]>

drm/amd/display: Rename panic function

Rename dc_plane_force_update_for_panic to
dc_plane_force_dcc_and_tiling_disable to describe the function operation
in the name. Also, this function might be us

drm/amd/display: Rename panic function

Rename dc_plane_force_update_for_panic to
dc_plane_force_dcc_and_tiling_disable to describe the function operation
in the name. Also, this function might be used in other contexts, and a
more generic name can be helpful for this purpose.

Reviewed-by: Alvin Lee <[email protected]>
Signed-off-by: Rodrigo Siqueira <[email protected]>
Signed-off-by: Roman Li <[email protected]>
Tested-by: Daniel Wheeler <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>

show more ...


Revision tags: v6.14-rc1
# 41129e23 27-Jan-2025 André Almeida <[email protected]>

drm/amdgpu: Enable async flip on overlay planes

amdgpu can handle async flips on overlay planes, so allow it for atomic
async checks.

Signed-off-by: André Almeida <[email protected]>
Acked-by:

drm/amdgpu: Enable async flip on overlay planes

amdgpu can handle async flips on overlay planes, so allow it for atomic
async checks.

Signed-off-by: André Almeida <[email protected]>
Acked-by: Alex Deucher <[email protected]>
Reviewed-by: Harry Wentland <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
[DB: fixed checkpatch warning by adding braces]
Signed-off-by: Dmitry Baryshkov <[email protected]>

show more ...


Revision tags: v6.13, v6.13-rc7, v6.13-rc6, v6.13-rc5, v6.13-rc4, v6.13-rc3, v6.13-rc2
# c7c703e4 02-Dec-2024 Karthi Kandasamy <[email protected]>

drm/amd/display: Ensure correct GFX tiling info passed to DML

[Why]
To ensure DML validation receives the correct tiling information,
such as swizzle mode or array mode, based on the active GFX form

drm/amd/display: Ensure correct GFX tiling info passed to DML

[Why]
To ensure DML validation receives the correct tiling information,
such as swizzle mode or array mode, based on the active GFX format

[How]
- For new GFX format passed swizzle_mode to DML.
- For legacy GFX format passed array_mode to DML.
- Dynamically determined the appropriate tiling info based on the
active GFX format.

[Description]
This commit ensures that the correct GFX tiling information is passed
to DML. Depending on the active GFX format, the appropriate tiling info
is passed to DML. This change accommodates the different GFX formats
supported by latest platforms, ensuring compatibility and proper
DML validation.

Reviewed-by: Alvin Lee <[email protected]>
Signed-off-by: Karthi Kandasamy <[email protected]>
Signed-off-by: Roman Li <[email protected]>
Tested-by: Daniel Wheeler <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>

show more ...


Revision tags: v6.13-rc1
# 080950cb 20-Nov-2024 Karthi Kandasamy <[email protected]>

drm/amd/display: Update dc_tiling_info union to structure

[WHY]
The `dc_tiling_info` union previously did not have a field to
specify the active GFX format, assuming only one format would
be used pe

drm/amd/display: Update dc_tiling_info union to structure

[WHY]
The `dc_tiling_info` union previously did not have a field to
specify the active GFX format, assuming only one format would
be used per DCN version. from DCN4+, support for switching
between different GFX formats is introduced, requiring a way
to track which format is currently in use.

[HOW]
Updated the `dc_tiling_info` union to include a new field that
explicitly indicates the currently used GFX format.
This allows the system to determine the active GFX format
and take the correct programming path accordingly.

[Description]
The union `dc_tiling_info` has been updated to support multiple
GFX formats by adding a new field for identifying the active format.
This update ensures that the correct programming path is followed
based on the selected format. All references to `dc_tiling_info`
in the codebase have been updated to reflect the new structure.

Reviewed-by: Alvin Lee <[email protected]>
Signed-off-by: Karthi Kandasamy <[email protected]>
Signed-off-by: Roman Li <[email protected]>
Tested-by: Daniel Wheeler <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>

show more ...


Revision tags: v6.12
# 04d6273f 14-Nov-2024 Rodrigo Siqueira <[email protected]>

Revert "drm/amd/display: Fix green screen issue after suspend"

This reverts commit 87b7ebc2e16c14d32a912f18206a4d6cc9abc3e8.

A long time ago, we had an issue with the Raven system when it was
conne

Revert "drm/amd/display: Fix green screen issue after suspend"

This reverts commit 87b7ebc2e16c14d32a912f18206a4d6cc9abc3e8.

A long time ago, we had an issue with the Raven system when it was
connected to two displays: one with DP and another with HDMI. After the
system woke up from suspension, we saw a solid green screen caused by an
underflow generated by bad DCC metadata. To workaround this issue, the
'commit 87b7ebc2e16c ("drm/amd/display: Fix green screen issue after
suspend")' was introduced to disable the DCC for a few frames after in
the resume phase. However, in hindsight, this solution was probably a
workaround at the kernel level for some issues from another part
(probably other driver components or user space). After applying this
patch and trying to reproduce the green issue in a similar hardware
system but using the latest kernel and userspace, we cannot see the
issue, which makes this workaround obsolete and creates extra
unnecessary complexity to the code; for all of this reason, this commit
reverts the original change.

Cc: Mario Limonciello <[email protected]>
Cc: Pierre-Eric Pelloux-Prayer <[email protected]>
Tested-by: Daniel Wheeler <[email protected]>
Reviewed-by: Aurabindo Pillai <[email protected]>
Signed-off-by: Rodrigo Siqueira <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>

show more ...


Revision tags: v6.12-rc7, v6.12-rc6
# 736692c3 31-Oct-2024 Jocelyn Falempe <[email protected]>

drm/amd/display: add DC drm_panic support

Add support for the drm_panic module, which displays a pretty user
friendly message on the screen when a Linux kernel panic occurs.

It doesn't work yet on

drm/amd/display: add DC drm_panic support

Add support for the drm_panic module, which displays a pretty user
friendly message on the screen when a Linux kernel panic occurs.

It doesn't work yet on laptop panels, maybe due to PSR.

Adapted from Jocelyn's original patch to add DC drm_panic
support.

Reviewed-by: Harry Wentland <[email protected]>
Signed-off-by: Jocelyn Falempe <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
Cc: Lu Yao <[email protected]>
Cc: Jocelyn Falempe <[email protected]>
Cc: Harry Wentland <[email protected]>

show more ...


Revision tags: v6.12-rc5, v6.12-rc4, v6.12-rc3, v6.12-rc2, v6.12-rc1, v6.11, v6.11-rc7, v6.11-rc6, v6.11-rc5, v6.11-rc4, v6.11-rc3, v6.11-rc2, v6.11-rc1, v6.10, v6.10-rc7, v6.10-rc6, v6.10-rc5, v6.10-rc4, v6.10-rc3
# 54b86443 05-Jun-2024 Christian König <[email protected]>

drm/amdgpu: explicitely set the AMDGPU_GEM_CREATE_VRAM_CONTIGUOUS flag

Instead of having that in the amdgpu_bo_pin() function applied for all
pinned BOs.

Signed-off-by: Christian König <christian.k

drm/amdgpu: explicitely set the AMDGPU_GEM_CREATE_VRAM_CONTIGUOUS flag

Instead of having that in the amdgpu_bo_pin() function applied for all
pinned BOs.

Signed-off-by: Christian König <[email protected]>
Acked-by: Lijo Lazar <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>

show more ...


# 3b9a3323 21-Aug-2024 Ma Ke <[email protected]>

drm/amd/display: avoid using null object of framebuffer

Instead of using state->fb->obj[0] directly, get object from framebuffer
by calling drm_gem_fb_get_obj() and return error code when object is

drm/amd/display: avoid using null object of framebuffer

Instead of using state->fb->obj[0] directly, get object from framebuffer
by calling drm_gem_fb_get_obj() and return error code when object is
null to avoid using null object of framebuffer.

Fixes: 5d945cbcd4b1 ("drm/amd/display: Create a file dedicated to planes")
Signed-off-by: Ma Ke <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
(cherry picked from commit 73dd0ad9e5dad53766ea3e631303430116f834b3)

show more ...


# 87d23164 14-Aug-2024 Aurabindo Pillai <[email protected]>

drm/amd/display: do not set traslate_by_source for DCN401 cursor

translate_by_source need not be set for DCN401 onwards since cursor
cursor composition comes after scaler in the hardware pipeline.
H

drm/amd/display: do not set traslate_by_source for DCN401 cursor

translate_by_source need not be set for DCN401 onwards since cursor
cursor composition comes after scaler in the hardware pipeline.
Hence offset calculation has been reworked, and this setting is not
necessary to be enabled anymore.

Reviewed-by: Rodrigo Siqueira <[email protected]>
Signed-off-by: Aurabindo Pillai <[email protected]>
Signed-off-by: Zaeem Mohamed <[email protected]>
Tested-by: Daniel Wheeler <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>

show more ...


# 73dd0ad9 21-Aug-2024 Ma Ke <[email protected]>

drm/amd/display: avoid using null object of framebuffer

Instead of using state->fb->obj[0] directly, get object from framebuffer
by calling drm_gem_fb_get_obj() and return error code when object is

drm/amd/display: avoid using null object of framebuffer

Instead of using state->fb->obj[0] directly, get object from framebuffer
by calling drm_gem_fb_get_obj() and return error code when object is
null to avoid using null object of framebuffer.

Fixes: 5d945cbcd4b1 ("drm/amd/display: Create a file dedicated to planes")
Signed-off-by: Ma Ke <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>

show more ...


# cd9e9e08 02-Aug-2024 Srinivasan Shanmugam <[email protected]>

drm/amd/display: Add null check for 'afb' in amdgpu_dm_plane_handle_cursor_update (v2)

This commit adds a null check for the 'afb' variable in the
amdgpu_dm_plane_handle_cursor_update function. Prev

drm/amd/display: Add null check for 'afb' in amdgpu_dm_plane_handle_cursor_update (v2)

This commit adds a null check for the 'afb' variable in the
amdgpu_dm_plane_handle_cursor_update function. Previously, 'afb' was
assumed to be null, but was used later in the code without a null check.
This could potentially lead to a null pointer dereference.

Changes since v1:
- Moved the null check for 'afb' to the line where 'afb' is used. (Alex)

Fixes the below:
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_plane.c:1298 amdgpu_dm_plane_handle_cursor_update() error: we previously assumed 'afb' could be null (see line 1252)

Cc: Tom Chung <[email protected]>
Cc: Rodrigo Siqueira <[email protected]>
Cc: Roman Li <[email protected]>
Cc: Alex Hung <[email protected]>
Cc: Aurabindo Pillai <[email protected]>
Cc: Harry Wentland <[email protected]>
Co-developed-by: Alex Hung <[email protected]>
Signed-off-by: Alex Hung <[email protected]>
Signed-off-by: Srinivasan Shanmugam <[email protected]>
Reviewed-by: Tom Chung <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>

show more ...


# 21e6f608 03-Jul-2024 Aurabindo Pillai <[email protected]>

drm/amd/display: Allow display DCC for DCN401

To enable mesa to use display dcc, DM should expose them in the
supported modifiers. Add the best (most efficient) modifiers first.

Signed-off-by: Aura

drm/amd/display: Allow display DCC for DCN401

To enable mesa to use display dcc, DM should expose them in the
supported modifiers. Add the best (most efficient) modifiers first.

Signed-off-by: Aurabindo Pillai <[email protected]>
Acked-by: Alex Deucher <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>

show more ...


# cc6e00a6 26-Jun-2024 Marek Olšák <[email protected]>

drm/amdgpu/display: add all gfx12 modifiers

Signed-off-by: Marek Olšák <[email protected]>
Acked-by: Alex Deucher <[email protected]>
Reviewed-by: Aurabindo Pillai <[email protected]

drm/amdgpu/display: add all gfx12 modifiers

Signed-off-by: Marek Olšák <[email protected]>
Acked-by: Alex Deucher <[email protected]>
Reviewed-by: Aurabindo Pillai <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>

show more ...


Revision tags: v6.10-rc2
# ce7985fd 01-Jun-2024 Marek Olšák <[email protected]>

drm/amdgpu/display: set plane attributes for gfx12 correctly

It used gfx9 flags, which has undefined behavior on gfx12.

Signed-off-by: Marek Olšák <[email protected]>
Acked-by: Alex Deucher <alex

drm/amdgpu/display: set plane attributes for gfx12 correctly

It used gfx9 flags, which has undefined behavior on gfx12.

Signed-off-by: Marek Olšák <[email protected]>
Acked-by: Alex Deucher <[email protected]>
Reviewed-by: Aurabindo Pillai <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>

show more ...


# ed17b63e 01-Jun-2024 Marek Olšák <[email protected]>

drm/amdgpu/display: handle gfx12 in amdgpu_dm_plane_format_mod_supported

All this code has undefined behavior on GFX12 and shouldn't be executed.

Signed-off-by: Marek Olšák <[email protected]>
Ac

drm/amdgpu/display: handle gfx12 in amdgpu_dm_plane_format_mod_supported

All this code has undefined behavior on GFX12 and shouldn't be executed.

Signed-off-by: Marek Olšák <[email protected]>
Acked-by: Alex Deucher <[email protected]>
Reviewed-by: Aurabindo Pillai <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>

show more ...


Revision tags: v6.10-rc1, v6.9, v6.9-rc7, v6.9-rc6, v6.9-rc5, v6.9-rc4, v6.9-rc3, v6.9-rc2, v6.9-rc1, v6.8, v6.8-rc7
# 38e0c3df 26-Feb-2024 Leo Li <[email protected]>

drm/amd/display: Move PRIMARY plane zpos higher

[Why]

Compositors have different ways of assigning surfaces to DRM planes for
render offloading. It may decide between various strategies: overlay,
u

drm/amd/display: Move PRIMARY plane zpos higher

[Why]

Compositors have different ways of assigning surfaces to DRM planes for
render offloading. It may decide between various strategies: overlay,
underlay, or a mix of both (see here for more info:
https://gitlab.freedesktop.org/emersion/libliftoff/-/issues/76)

One way for compositors to implement the underlay strategy is to assign
a higher zpos to the DRM_PRIMARY plane than the DRM_OVERLAY planes,
effectively turning the DRM_OVERLAY plane into an underlay plane.

Today, amdgpu attaches an immutable zpos of 0 to the DRM_PRIMARY plane.
This however, is an arbitrary restriction. DCN pipes are general
purpose, and can be arranged in any z-order. To support compositors
using this allocation scheme, we can set a non-zero immutable zpos for
the PRIMARY, allowing the placement of OVERLAYS (mutable zpos range
0-254) beneath the PRIMARY.

[How]

Assign a zpos = #no of OVERLAY planes to the PRIMARY plane. Then, clean
up any assumptions in the driver of PRIMARY plane having the lowest
zpos.

v2: Fix typo s/decending/descending/

Reviewed-by: Harry Wentland <[email protected]>
Acked-by: Zaeem Mohamed <[email protected]>
Signed-off-by: Leo Li <[email protected]>
Acked-by: Pekka Paalanen <[email protected]>
Tested-by: Daniel Wheeler <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>

show more ...


Revision tags: v6.8-rc6, v6.8-rc5, v6.8-rc4, v6.8-rc3, v6.8-rc2, v6.8-rc1
# 1b04dcca 18-Jan-2024 Leo Li <[email protected]>

drm/amd/display: Introduce overlay cursor mode

[Why]

DCN is the display hardware for amdgpu. DRM planes are backed by DCN
hardware pipes, which carry pixel data from one end (memory), to the
other

drm/amd/display: Introduce overlay cursor mode

[Why]

DCN is the display hardware for amdgpu. DRM planes are backed by DCN
hardware pipes, which carry pixel data from one end (memory), to the
other (output encoder).

Each DCN pipe has the ability to blend in a cursor early on in the
pipeline. In other words, there are no dedicated cursor planes in DCN,
which makes cursor behavior somewhat unintuitive for compositors.

For example, if the cursor is in RGB format, but the top-most DRM plane
is in YUV format, DCN will not be able to blend them. Because of this,
amdgpu_dm rejects all configurations where a cursor needs to be enabled
on top of a YUV formatted plane.

From a compositor's perspective, when computing an allocation for
hardware plane offloading, this cursor-on-yuv configuration result in an
atomic test failure. Since the failure reason is not obvious at all,
compositors will likely fall back to full rendering, which is not ideal.

Instead, amdgpu_dm can try to accommodate the cursor-on-yuv
configuration by opportunistically reserving a separate DCN pipe just
for the cursor. We can refer to this as "overlay cursor mode". It is
contrasted with "native cursor mode", where the native DCN per-pipe
cursor is used.

[How]

On each crtc, compute whether the cursor plane should be enabled in
overlay mode. If it is, mark the CRTC as requesting overlay cursor mode.

Overlay cursor should be enabled whenever there exists a underlying
plane that has YUV format, or is scaled differently than the cursor. It
should also be enabled if there is no underlying plane, or if underlying
planes do not cover the entire CRTC.

During DC validation, attempt to enable a separate DCN pipe for the
cursor if it's in overlay mode. If that fails, or if no overlay mode is
requested, then fallback to native mode.

v2:
* Update commit message for when overlay cursor should be enabled
* Also consider scale and no-underlying-plane case (cursor on crtc bg)
* Consider all underlying planes when determinig overlay/native, not
just the plane immediately beneath the cursor, as it may not cover the
entire CRTC.
* Fix typo s/decending/descending/
* Force native cursor on pre-DCN hardware

Reviewed-by: Harry Wentland <[email protected]>
Acked-by: Zaeem Mohamed <[email protected]>
Signed-off-by: Leo Li <[email protected]>
Acked-by: Harry Wentland <[email protected]>
Acked-by: Pekka Paalanen <[email protected]>
Tested-by: Daniel Wheeler <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>

show more ...


# 778e3979 07-Jun-2024 Ivan Lipski <[email protected]>

Revert "drm/amd/display: Add NULL check for 'afb' before dereferencing in amdgpu_dm_plane_handle_cursor_update"

[WHY]
This patch is a dupplicate implementation of 14bcf29b, which we
are reverting du

Revert "drm/amd/display: Add NULL check for 'afb' before dereferencing in amdgpu_dm_plane_handle_cursor_update"

[WHY]
This patch is a dupplicate implementation of 14bcf29b, which we
are reverting due to a regression with kms_plane_cursor IGT tests.

This reverts commit 38e6f715b02b572f74677eb2f29d3b4bc6f1ddff.

Reviewed-by: Srinivasan Shanmugam <[email protected]>
Tested-by: George Zhang <[email protected]>
Signed-off-by: Ivan Lipski <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>

show more ...


# 38e6f715 05-Jun-2024 Srinivasan Shanmugam <[email protected]>

drm/amd/display: Add NULL check for 'afb' before dereferencing in amdgpu_dm_plane_handle_cursor_update

This commit adds a null check for the 'afb' variable in the
amdgpu_dm_plane_handle_cursor_updat

drm/amd/display: Add NULL check for 'afb' before dereferencing in amdgpu_dm_plane_handle_cursor_update

This commit adds a null check for the 'afb' variable in the
amdgpu_dm_plane_handle_cursor_update function. Previously, 'afb' was
assumed to be null, but was used later in the code without a null check.
This could potentially lead to a null pointer dereference.

Fixes the below:
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_plane.c:1298 amdgpu_dm_plane_handle_cursor_update() error: we previously assumed 'afb' could be null (see line 1252)

Cc: Tom Chung <[email protected]>
Cc: Rodrigo Siqueira <[email protected]>
Cc: Roman Li <[email protected]>
Cc: Hersen Wu <[email protected]>
Cc: Alex Hung <[email protected]>
Cc: Aurabindo Pillai <[email protected]>
Cc: Harry Wentland <[email protected]>
Signed-off-by: Srinivasan Shanmugam <[email protected]>
Reviewed-by: Harry Wentland <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>

show more ...


# 66eba12a 15-Mar-2024 Harry Wentland <[email protected]>

drm/amd/display: Do cursor programming with rest of pipe

Cursors are always programmed independently of updates on other
planes. When atomic commits program cursor and surface updates
together the c

drm/amd/display: Do cursor programming with rest of pipe

Cursors are always programmed independently of updates on other
planes. When atomic commits program cursor and surface updates
together the cursor update might be locked out by the surface
update and not take effect.

To combat this program cursor and surface updates together via
dc_update_planes_and_stream to ensure they can be applied
atomically.

When cursor updates come on their own use the old method
to program the cursor as dc_update_planes_and_stream isn't
handling this case correctly (yet), leading to a flickering
screen.

Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/2186
Reviewed-by: Agustin Gutierrez <[email protected]>
Acked-by: Wayne Lin <[email protected]>
Signed-off-by: Harry Wentland <[email protected]>
Tested-by: Daniel Wheeler <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>

show more ...


# f63f86b5 15-Mar-2024 Harry Wentland <[email protected]>

drm/amd/display: Separate setting and programming of cursor

We're seeing issues when user-space tries to do an atomic update of
the primary surface, as well as the cursor. These two updates are
sepa

drm/amd/display: Separate setting and programming of cursor

We're seeing issues when user-space tries to do an atomic update of
the primary surface, as well as the cursor. These two updates are
separate calls into DC and don't currently act as an atomic update.
This might lead to cursor updates being locked out and cursors
stuttering.

In order to solve this problem we want to separate the setting
and programming of cursor attributes and position. That's what
we're doing in this patch. The subsequent patch will then be
able to use the cursor setters in independent cursor updates,
as well as in atomic commits.

Reviewed-by: Agustin Gutierrez <[email protected]>
Acked-by: Aurabindo Pillai <[email protected]>
Signed-off-by: Harry Wentland <[email protected]>
Tested-by: Daniel Wheeler <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>

show more ...


# a64a5212 02-Feb-2024 Aurabindo Pillai <[email protected]>

drm/amd/display: Add gfx12 modifiers

Expose linear modifier definitions for use with DCN401

Signed-off-by: Aurabindo Pillai <[email protected]>
Acked-by: Rodrigo Siqueira <rodrigo.siqueira@a

drm/amd/display: Add gfx12 modifiers

Expose linear modifier definitions for use with DCN401

Signed-off-by: Aurabindo Pillai <[email protected]>
Acked-by: Rodrigo Siqueira <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>

show more ...


123