linux-stable.git/drivers/gpu/drm/amd/display/amdgpu_dm, branch linux-5.11.y

drm/amd/display: Initialize attribute for hdcp_srm sysfs file

2021-05-19T08:29:50+00:00

commit fe1c97d008f86f672f0e9265f180c22451ca3b9f upstream.

It is stored in dynamically allocated memory, so sysfs_bin_attr_init() must
be called to initialize it. (Note: "initialization" only sets the .attr.key
member in this struct; it does not change the value of any other members.)

Otherwise, when CONFIG_DEBUG_LOCK_ALLOC=y this message appears during boot:

    BUG: key ffff9248900cd148 has not been registered!

Fixes: 9037246bb2da ("drm/amd/display: Add sysfs interface for set/get srm")
Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1586
Reported-by: Mikhail Gavrilov 
Signed-off-by: David Ward 
Signed-off-by: Alex Deucher 
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman

drm/amd/display: check fb of primary plane

2021-05-14T08:49:56+00:00

[ Upstream commit 7df4ceb60fa9a3c5160cfd5b696657291934a2c9 ]

Sometimes the primary plane might not be initialized (yet), which
causes dm_check_crtc_cursor to divide by zero.
Apparently a weird state before a S3-suspend causes the aforementioned
divide-by-zero error when resuming from S3.  This was explained in
bug 212293 on Bugzilla.

To avoid this divide-by-zero error we check if the primary plane's fb
isn't NULL.  If it's NULL the src_w and src_h attributes will be 0,
which would cause a divide-by-zero.

This fixes Bugzilla report 212293
Bug: https://bugzilla.kernel.org/show_bug.cgi?id=212293

Fixes: 12f4849a1cfd69f3 ("drm/amd/display: check cursor scaling")
Reviewed-by: Simon Ser 
Reviewed-by: Harry Wentland 
Signed-off-by: Sefa Eyeoglu 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin

drm/amd/display: Reject non-zero src_y and src_x for video planes

2021-05-14T08:49:28+00:00

commit d89f6048bdcb6a56abb396c584747d5eeae650db upstream.

[Why]
This hasn't been well tested and leads to complete system hangs on DCN1
based systems, possibly others.

The system hang can be reproduced by gesturing the video on the YouTube
Android app on ChromeOS into full screen.

[How]
Reject atomic commits with non-zero drm_plane_state.src_x or src_y values.

v2:
 - Add code comment describing the reason we're rejecting non-zero
   src_x and src_y
 - Drop gerrit Change-Id
 - Add stable CC
 - Based on amd-staging-drm-next

v3: removed trailing whitespace

Signed-off-by: Harry Wentland 
Cc: stable@vger.kernel.org
Cc: nicholas.kazlauskas@amd.com
Cc: amd-gfx@lists.freedesktop.org
Cc: alexander.deucher@amd.com
Cc: Roman.Li@amd.com
Cc: hersenxs.wu@amd.com
Cc: danny.wang@amd.com
Reviewed-by: Nicholas Kazlauskas 
Acked-by: Christian König 
Reviewed-by: Hersen Wu 
Signed-off-by: Alex Deucher 
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman

drm/amd/display: Try YCbCr420 color when YCbCr444 fails

2021-05-12T06:37:28+00:00

[ Upstream commit 68eb3ae3c63708f823aeeb63bb15197c727bd9bf ]

When encoder validation of a display mode fails, retry with less bandwidth
heavy YCbCr420 color mode, if available. This enables some HDMI 1.4 setups
to support 4k60Hz output, which previously failed silently.

On some setups, while the monitor and the gpu support display modes with
pixel clocks of up to 600MHz, the link encoder might not. This prevents
YCbCr444 and RGB encoding for 4k60Hz, but YCbCr420 encoding might still be
possible. However, which color mode is used is decided before the link
encoder capabilities are checked. This patch fixes the problem by retrying
to find a display mode with YCbCr420 enforced and using it, if it is
valid.

Reviewed-by: Harry Wentland 
Signed-off-by: Werner Sembach 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin

drm/amd/display: Fix debugfs link_settings entry

2021-05-12T06:37:27+00:00

[ Upstream commit c006a1c00de29e8cdcde1d0254ac23433ed3fee9 ]

1. Catch invalid link_rate and link_count settings
2. Call dc interface to overwrite preferred link settings, and wait
until next stream update to apply the new settings.

Tested-by: Daniel Wheeler 
Signed-off-by: Fangzhi Zuo 
Reviewed-by: Nicholas Kazlauskas 
Acked-by: Solomon Chiu 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin

drm/amd/display: Fix UBSAN warning for not a valid value for type '_Bool'

2021-05-12T06:37:23+00:00

[ Upstream commit 6a30a92997eee49554f72b462dce90abe54a496f ]

[Why]
dc_cursor_position do not initialise position.translate_by_source when
crtc or plane->state->fb is NULL. UBSAN caught this error in
dce110_set_cursor_position, as the value was garbage.

[How]
Initialise dc_cursor_position structure elements to 0 in handle_cursor_update
before calling get_cursor_position.

Tested-by: Daniel Wheeler 
Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1471
Reported-by: Lyude Paul 
Signed-off-by: Anson Jacob 
Reviewed-by: Aurabindo Jayamohanan Pillai 
Acked-by: Solomon Chiu 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin

drm/amdgpu/display: buffer INTERRUPT_LOW_IRQ_CONTEXT interrupt work

2021-05-12T06:37:20+00:00

[ Upstream commit b6f91fc183f758461b9462cc93e673adbbf95c2d ]

amdgpu DM handles INTERRUPT_LOW_IRQ_CONTEXT interrupt(hpd, hpd_rx) by using work
queue and uses single work_struct. If new interrupt is recevied before the
previous handler finished, new interrupts(same type) will be discarded and
driver just sends "amdgpu_dm_irq_schedule_work FAILED" message out. If some
important hpd, hpd_rx related interrupts are missed by driver the hot (un)plug
devices may cause system hang or instability, such as issues with system
resume from S3 sleep with mst device connected.

This patch dynamically allocates new amdgpu_dm_irq_handler_data for new
interrupts if previous INTERRUPT_LOW_IRQ_CONTEXT interrupt work has not been
handled. So the new interrupt works can be queued to the same workqueue_struct,
instead of discard the new interrupts. All allocated amdgpu_dm_irq_handler_data
are put into a single linked list and will be reused after.

Signed-off-by: Xiaogang Chen 
Reviewed-by: Aurabindo Pillai 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin

drm/amd/display: Check for DSC support instead of ASIC revision

2021-05-12T06:37:19+00:00

[ Upstream commit 349a19b2f1b01e713268c7de9944ad669ccdf369 ]

[why]
This check for ASIC revision is no longer useful and causes
lightup issues after a topology change in MST DSC scenario.
In this case, DSC configs should be recalculated for the new
topology. This check prevented that from happening on certain
ASICs that do, in fact, support DSC.

[how]
Change the ASIC revision to instead check if DSC is supported.

Signed-off-by: Eryk Brol 
Acked-by: Bindu Ramamurthy 
Tested-by: Daniel Wheeler 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin

drm/amd/display: Update modifier list for gfx10_3

2021-05-02T09:07:29+00:00

commit 6d638b3ffd27036c062d32cb4efd4be172c2a65e upstream.

[Why]
Current list supports modifiers that have DCC_MAX_COMPRESSED_BLOCK
set to AMD_FMT_MOD_DCC_BLOCK_128B, while AMD_FMT_MOD_DCC_BLOCK_64B
is used instead by userspace.

[How]
Replace AMD_FMT_MOD_DCC_BLOCK_128B with AMD_FMT_MOD_DCC_BLOCK_64B
for modifiers with DCC supported.

Fixes: faa37f54ce0462 ("drm/amd/display: Expose modifiers")
Signed-off-by: Qingqing Zhuo 
Reviewed-by: Bas Nieuwenhuizen 
Tested-by: Bas Nieuwenhuizen 
Signed-off-by: Alex Deucher 
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman

amd/display: allow non-linear multi-planar formats

2021-04-28T11:41:47+00:00

commit 9ebb6bc0125dfb1e65a53eea4aeecc63d4d6ec2d upstream.

Accept non-linear buffers which use a multi-planar format, as long
as they don't use DCC.

Tested on GFX9 with NV12.

Signed-off-by: Simon Ser 
Cc: Alex Deucher 
Cc: Harry Wentland 
Cc: Nicholas Kazlauskas 
Cc: Bas Nieuwenhuizen 
Reviewed-by: Bas Nieuwenhuizen 
Signed-off-by: Alex Deucher 
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman