Re: [PATCH 1/2] drm/amd/display: Introduce overlay cursor mode
On 2024-03-28 11:52, Harry Wentland wrote:
On 2024-03-28 11:48, Robert Mader wrote:
Hi,
On 15.03.24 18:09, sunpeng...@amd.com wrote:
From: Leo Li
[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 (which currently, is iff the immediate plane below has a
YUV format). If it is, mark the CRTC as requesting overlay cursor mode.
iff -> if
IIRC another case where this would be needed is when the scale of the plane
below doesn't match the cursor scale. This is especially common for videos and
thus implicitly covered by the YUV check in most cases, but should probably be
made explicit. Michel Dänzer might be able to comment here.
Another possible case that could be covered here is when some area is not
covered by any plane and just shows a black background. This happens e.g. if a
compositor puts a YUV surface on the primary plane that has a different
width/high ratio than the display. The compositor can add black bars by just
leaving the area uncovered and thus require only a single hardware plane for
video playback ("Unless explicitly specified (..), the active area of a CRTC
will be black by default."
https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#plane-abstraction). If
the cursor is visible over this black bars, AMD currently refuses the commit
IIUC (see also Michel Dänzers comment at
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3177#note_1924544)
Thanks for mentioning both of these scenarios. I agree it would be
good if we can expand the use of the overlay cursor to these cases.
Harry
Thanks,
Robert Mader
All good points, thanks for the feedback. I'll take a peek at the scaling + no
underlying plane case and send a v2 when I get around to it.
Leo
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.
Signed-off-by: Leo Li
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 309 +++---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 7 +
.../amd/display/amdgpu_dm/amdgpu_dm_crtc.c | 1 +
.../amd/display/amdgpu_dm/amdgpu_dm_plane.c | 13 +-
4 files changed, 288 insertions(+), 42 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 21a61454c878..09ab330aed17 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -8359,8 +8359,19 @@ static void amdgpu_dm_commit_planes(struct
drm_atomic_state *state,
* Disable the cursor first if we're disabling all the planes.
* It'll remain on the screen after the planes are re-enabled
* if we don't.
+ *
+ * If the cursor is transitioning from native to overlay mode, the
+ * native cursor needs to be disabled first.
*/
- if (acrtc_state->active_planes == 0)
+ if (acrtc_state->cursor_mode == DM_CURSOR_OVERLAY_MODE &&
+ dm_old_crtc_state->cursor_mode == DM_CURSOR_NATIVE_MODE) {
+ struct dc_cursor_position cursor_position = {0};
+ dc_stream_set_cursor_position(acrtc_state->stream,
+ _position);
+ }
+
+ if (acrtc_state->active_planes == 0 &&
+ dm_old_crtc_state->cursor_mode == DM_CURSOR_NATIVE_MODE)
amdgpu_dm_commit_cursors(state);
/* update planes when needed */
@@ -8374,7 +8385,8 @@ static void amdgpu_dm_commit_planes(struct
drm_atomic_state *state,
struct dm_plane_state *dm_new_plane_state =
to_dm_plane_state(new_plane_state);
/* Cursor plane is handled after stream updates */
- if (plane->type == DRM_PLANE_TYPE_CURSOR) {
+ if (plane->type ==
Re: [PATCH 1/2] drm/amd/display: Introduce overlay cursor mode
Hi,
On 15.03.24 18:09, sunpeng...@amd.com wrote:
From: Leo Li
[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 (which currently, is iff the immediate plane below has a
YUV format). If it is, mark the CRTC as requesting overlay cursor mode.
iff -> if
IIRC another case where this would be needed is when the scale of the
plane below doesn't match the cursor scale. This is especially common
for videos and thus implicitly covered by the YUV check in most cases,
but should probably be made explicit. Michel Dänzer might be able to
comment here.
Another possible case that could be covered here is when some area is
not covered by any plane and just shows a black background. This happens
e.g. if a compositor puts a YUV surface on the primary plane that has a
different width/high ratio than the display. The compositor can add
black bars by just leaving the area uncovered and thus require only a
single hardware plane for video playback ("Unless explicitly specified
(..), the active area of a CRTC will be black by default."
https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#plane-abstraction).
If the cursor is visible over this black bars, AMD currently refuses the
commit IIUC (see also Michel Dänzers comment at
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3177#note_1924544)
Thanks,
Robert Mader
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.
Signed-off-by: Leo Li
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 309 +++---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 7 +
.../amd/display/amdgpu_dm/amdgpu_dm_crtc.c| 1 +
.../amd/display/amdgpu_dm/amdgpu_dm_plane.c | 13 +-
4 files changed, 288 insertions(+), 42 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 21a61454c878..09ab330aed17 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -8359,8 +8359,19 @@ static void amdgpu_dm_commit_planes(struct
drm_atomic_state *state,
* Disable the cursor first if we're disabling all the planes.
* It'll remain on the screen after the planes are re-enabled
* if we don't.
+*
+* If the cursor is transitioning from native to overlay mode, the
+* native cursor needs to be disabled first.
*/
- if (acrtc_state->active_planes == 0)
+ if (acrtc_state->cursor_mode == DM_CURSOR_OVERLAY_MODE &&
+ dm_old_crtc_state->cursor_mode == DM_CURSOR_NATIVE_MODE) {
+ struct dc_cursor_position cursor_position = {0};
+ dc_stream_set_cursor_position(acrtc_state->stream,
+ _position);
+ }
+
+ if (acrtc_state->active_planes == 0 &&
+ dm_old_crtc_state->cursor_mode == DM_CURSOR_NATIVE_MODE)
amdgpu_dm_commit_cursors(state);
/* update planes when needed */
@@ -8374,7 +8385,8 @@ static void amdgpu_dm_commit_planes(struct
drm_atomic_state *state,
struct dm_plane_state *dm_new_plane_state =
to_dm_plane_state(new_plane_state);
/* Cursor plane is handled after stream updates */
- if (plane->type == DRM_PLANE_TYPE_CURSOR) {
+ if (plane->type == DRM_PLANE_TYPE_CURSOR &&
+ acrtc_state->cursor_mode == DM_CURSOR_NATIVE_MODE) {
if ((fb && crtc == pcrtc) ||
(old_plane_state->fb && old_plane_state->crtc ==
pcrtc))
cursor_update = true;
@@ -8727,7 +8739,8
Re: [PATCH 1/2] drm/amd/display: Introduce overlay cursor mode
On 2024-03-28 11:48, Robert Mader wrote:
Hi,
On 15.03.24 18:09, sunpeng...@amd.com wrote:
From: Leo Li
[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 (which currently, is iff the immediate plane below has a
YUV format). If it is, mark the CRTC as requesting overlay cursor mode.
iff -> if
IIRC another case where this would be needed is when the scale of the
plane below doesn't match the cursor scale. This is especially common
for videos and thus implicitly covered by the YUV check in most cases,
but should probably be made explicit. Michel Dänzer might be able to
comment here.
Another possible case that could be covered here is when some area is
not covered by any plane and just shows a black background. This happens
e.g. if a compositor puts a YUV surface on the primary plane that has a
different width/high ratio than the display. The compositor can add
black bars by just leaving the area uncovered and thus require only a
single hardware plane for video playback ("Unless explicitly specified
(..), the active area of a CRTC will be black by default."
https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#plane-abstraction). If the cursor is visible over this black bars, AMD currently refuses the commit IIUC (see also Michel Dänzers comment at https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3177#note_1924544)
Thanks for mentioning both of these scenarios. I agree it would be
good if we can expand the use of the overlay cursor to these cases.
Harry
Thanks,
Robert Mader
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.
Signed-off-by: Leo Li
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 309 +++---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 7 +
.../amd/display/amdgpu_dm/amdgpu_dm_crtc.c | 1 +
.../amd/display/amdgpu_dm/amdgpu_dm_plane.c | 13 +-
4 files changed, 288 insertions(+), 42 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 21a61454c878..09ab330aed17 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -8359,8 +8359,19 @@ static void amdgpu_dm_commit_planes(struct
drm_atomic_state *state,
* Disable the cursor first if we're disabling all the planes.
* It'll remain on the screen after the planes are re-enabled
* if we don't.
+ *
+ * If the cursor is transitioning from native to overlay mode, the
+ * native cursor needs to be disabled first.
*/
- if (acrtc_state->active_planes == 0)
+ if (acrtc_state->cursor_mode == DM_CURSOR_OVERLAY_MODE &&
+ dm_old_crtc_state->cursor_mode == DM_CURSOR_NATIVE_MODE) {
+ struct dc_cursor_position cursor_position = {0};
+ dc_stream_set_cursor_position(acrtc_state->stream,
+ _position);
+ }
+
+ if (acrtc_state->active_planes == 0 &&
+ dm_old_crtc_state->cursor_mode == DM_CURSOR_NATIVE_MODE)
amdgpu_dm_commit_cursors(state);
/* update planes when needed */
@@ -8374,7 +8385,8 @@ static void amdgpu_dm_commit_planes(struct
drm_atomic_state *state,
struct dm_plane_state *dm_new_plane_state =
to_dm_plane_state(new_plane_state);
/* Cursor plane is handled after stream updates */
- if (plane->type == DRM_PLANE_TYPE_CURSOR) {
+ if (plane->type == DRM_PLANE_TYPE_CURSOR &&
+ acrtc_state->cursor_mode == DM_CURSOR_NATIVE_MODE) {
if ((fb && crtc == pcrtc) ||
(old_plane_state->fb && old_plane_state->crtc ==
pcrtc))
Re: [PATCH 1/2] drm/amd/display: Introduce overlay cursor mode
On Fri, 15 Mar 2024 13:09:57 -0400 wrote: > From: Leo Li > > [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. I can't comment on the code, but this explanation sounds like a really good move! Thanks, pq > [How] > > On each crtc, compute whether the cursor plane should be enabled in > overlay mode (which currently, is iff the immediate plane below has a > YUV format). If it is, mark the CRTC as requesting overlay cursor mode. > > 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. > > Signed-off-by: Leo Li > --- > .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 309 +++--- > .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 7 + > .../amd/display/amdgpu_dm/amdgpu_dm_crtc.c| 1 + > .../amd/display/amdgpu_dm/amdgpu_dm_plane.c | 13 +- > 4 files changed, 288 insertions(+), 42 deletions(-) pgpmymMkUxYuo.pgp Description: OpenPGP digital signature
Re: [PATCH 1/2] drm/amd/display: Introduce overlay cursor mode
On 2024-03-15 13:09, sunpeng...@amd.com wrote:
> From: Leo Li
>
> [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 (which currently, is iff the immediate plane below has a
> YUV format). If it is, mark the CRTC as requesting overlay cursor mode.
>
> 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.
>
> Signed-off-by: Leo Li
We should run this through our usual testing cycle, and I need to go over
it a bit more closely than I have, but I like it, so it's
Acked-by: Harry Wentland
Harry
> ---
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 309 +++---
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 7 +
> .../amd/display/amdgpu_dm/amdgpu_dm_crtc.c| 1 +
> .../amd/display/amdgpu_dm/amdgpu_dm_plane.c | 13 +-
> 4 files changed, 288 insertions(+), 42 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 21a61454c878..09ab330aed17 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -8359,8 +8359,19 @@ static void amdgpu_dm_commit_planes(struct
> drm_atomic_state *state,
>* Disable the cursor first if we're disabling all the planes.
>* It'll remain on the screen after the planes are re-enabled
>* if we don't.
> + *
> + * If the cursor is transitioning from native to overlay mode, the
> + * native cursor needs to be disabled first.
>*/
> - if (acrtc_state->active_planes == 0)
> + if (acrtc_state->cursor_mode == DM_CURSOR_OVERLAY_MODE &&
> + dm_old_crtc_state->cursor_mode == DM_CURSOR_NATIVE_MODE) {
> + struct dc_cursor_position cursor_position = {0};
> + dc_stream_set_cursor_position(acrtc_state->stream,
> + _position);
> + }
> +
> + if (acrtc_state->active_planes == 0 &&
> + dm_old_crtc_state->cursor_mode == DM_CURSOR_NATIVE_MODE)
> amdgpu_dm_commit_cursors(state);
>
> /* update planes when needed */
> @@ -8374,7 +8385,8 @@ static void amdgpu_dm_commit_planes(struct
> drm_atomic_state *state,
> struct dm_plane_state *dm_new_plane_state =
> to_dm_plane_state(new_plane_state);
>
> /* Cursor plane is handled after stream updates */
> - if (plane->type == DRM_PLANE_TYPE_CURSOR) {
> + if (plane->type == DRM_PLANE_TYPE_CURSOR &&
> + acrtc_state->cursor_mode == DM_CURSOR_NATIVE_MODE) {
> if ((fb && crtc == pcrtc) ||
> (old_plane_state->fb && old_plane_state->crtc ==
> pcrtc))
> cursor_update = true;
> @@ -8727,7 +8739,8 @@ static void amdgpu_dm_commit_planes(struct
> drm_atomic_state *state,
>* This avoids redundant programming in the case where we're going
>* to be disabling a single plane - those pipes are being disabled.
>*/
> - if (acrtc_state->active_planes)
> + if (acrtc_state->active_planes &&
> + acrtc_state->cursor_mode == DM_CURSOR_NATIVE_MODE)
> amdgpu_dm_commit_cursors(state);
>
> cleanup:
> @@ -10039,7 +10052,8 @@ static bool should_reset_plane(struct
> drm_atomic_state *state,
> {
> struct drm_plane *other;
> struct drm_plane_state *old_other_state, *new_other_state;
> - struct drm_crtc_state *new_crtc_state;
> + struct drm_crtc_state *old_crtc_state, *new_crtc_state;
> + struct dm_crtc_state *old_dm_crtc_state,
Re: [PATCH 1/2] drm/amd/display: Introduce overlay cursor mode
Hi,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on drm/drm-next drm-exynos/exynos-drm-next
drm-intel/for-linux-next drm-intel/for-linux-next-fixes drm-tip/drm-tip
linus/master v6.8 next-20240315]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/sunpeng-li-amd-com/drm-amd-display-Introduce-overlay-cursor-mode/20240316-011404
base: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
patch link:
https://lore.kernel.org/r/20240315170959.165505-2-sunpeng.li%40amd.com
patch subject: [PATCH 1/2] drm/amd/display: Introduce overlay cursor mode
config: loongarch-defconfig
(https://download.01.org/0day-ci/archive/20240316/202403161600.6kspdesj-...@intel.com/config)
compiler: loongarch64-linux-gcc (GCC) 13.2.0
reproduce (this is a W=1 build):
(https://download.01.org/0day-ci/archive/20240316/202403161600.6kspdesj-...@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot
| Closes:
https://lore.kernel.org/oe-kbuild-all/202403161600.6kspdesj-...@intel.com/
All warnings (new ones prefixed by >>):
>> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:10639: warning:
>> This comment starts with '/**', but isn't a kernel-doc comment. Refer
>> Documentation/doc-guide/kernel-doc.rst
* Set whether the cursor should be enabled in native mode, or overlay mode,
on
vim +10639 drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c
10637
10638 /**
10639 * Set whether the cursor should be enabled in native mode, or overlay
mode, on
10640 * the dm_crtc_state.
10641 *
10642 * The cursor should be enabled in overlay mode if the immediate
underlying
10643 * plane contains a video format.
10644 *
10645 * Since zpos info is required, drm_atomic_normalize_zpos must be
called before
10646 * calling this function.
10647 */
10648 static int dm_crtc_set_cursor_mode(struct drm_atomic_state *state,
10649 struct dm_crtc_state *dm_crtc_state)
10650 {
10651 struct drm_plane_state *plane_state, *old_plane_state,
*target_plane_state;
10652 struct drm_crtc_state *crtc_state = _crtc_state->base;
10653 struct drm_plane *plane;
10654 bool consider_mode_change = false;
10655 bool cursor_changed = false;
10656 unsigned int target_zpos;
10657 unsigned int cursor_zpos;
10658 int i;
10659
10660 /*
10661 * Cursor mode can change if a plane's format changes, is
10662 * enabled/disabled, or z-order changes.
10663 */
10664 for_each_oldnew_plane_in_state(state, plane, old_plane_state,
plane_state, i) {
10665
10666 /* Only care about planes on this CRTC */
10667 if ((drm_plane_mask(plane) & crtc_state->plane_mask) ==
0)
10668 continue;
10669
10670 if (plane->type == DRM_PLANE_TYPE_CURSOR)
10671 cursor_changed = true;
10672
10673 if (drm_atomic_plane_enabling(old_plane_state,
plane_state) ||
10674 drm_atomic_plane_disabling(old_plane_state,
plane_state) ||
10675 old_plane_state->fb->format !=
plane_state->fb->format) {
10676 consider_mode_change = true;
10677 break;
10678 }
10679 }
10680
10681 if (!consider_mode_change && !crtc_state->zpos_changed) {
10682 return 0;
10683 }
10684
10685 /*
10686 * If no cursor change on this CRTC, and not enabled on this
CRTC, then
10687 * no need to set cursor mode. This avoids needlessly locking
the cursor
10688 * state.
10689 */
10690 if (!cursor_changed &&
10691 !(drm_plane_mask(crtc_state->crtc->cursor) &
crtc_state->plane_mask)) {
10692 return 0;
10693 }
10694
10695 plane_state = drm_atomic_get_plane_state(state,
10696
crtc_state->crtc->cursor);
10697 if (IS_ERR(plane_state))
10698 return PTR_ERR(plane_state);
10699
10700 /* Cursor is disabled */
10701 if (!plane_state->fb)
10702 return 0;
10703
10704 cursor_zpos = plane_state->normalized_zpos;
10705
10706 /* Get enabled plane immediately below cursor. */
10707 target_plane_state = NULL;
10708 target_zpos = 0;
