linux-stable.git/drivers/gpu/drm/amd, branch v5.1.9

drm/amd: fix fb references in async update

2019-06-11T10:19:23+00:00

commit 332af874db929f92931727bfe191b2c666438c81 upstream.

Async update callbacks are expected to set the old_fb in the new_state
so prepare/cleanup framebuffers are balanced.

Calling drm_atomic_set_fb_for_plane() (which gets a reference of the new
fb and put the old fb) is not required, as it's taken care by
drm_mode_cursor_universal() when calling drm_atomic_helper_update_plane().

Cc:  # v4.20+
Fixes: 674e78acae0d ("drm/amd/display: Add fast path for cursor plane updates")
Suggested-by: Boris Brezillon 
Signed-off-by: Helen Koike 
Reviewed-by: Nicholas Kazlauskas 
Signed-off-by: Boris Brezillon 
Link: https://patchwork.freedesktop.org/patch/msgid/20190603165610.24614-3-helen.koike@collabora.com
Signed-off-by: Greg Kroah-Hartman

drm/amdgpu: fix ring test failure issue during s3 in vce 3.0 (V2)

2019-06-11T10:19:22+00:00

commit ce0e22f5d886d1b56c7ab4347c45b9ac5fcc058d upstream.

[What]
vce ring test fails consistently during resume in s3 cycle, due to
mismatch read & write pointers.
On debug/analysis its found that rptr to be compared is not being
correctly updated/read, which leads to this failure.
Below is the failure signature:
	[drm:amdgpu_vce_ring_test_ring] *ERROR* amdgpu: ring 12 test failed
	[drm:amdgpu_device_ip_resume_phase2] *ERROR* resume of IP block  failed -110
	[drm:amdgpu_device_resume] *ERROR* amdgpu_device_ip_resume failed (-110).

[How]
fetch rptr appropriately, meaning move its read location further down
in the code flow.
With this patch applied the s3 failure is no more seen for >5k s3 cycles,
which otherwise is pretty consistent.

V2: remove reduntant fetch of rptr

Signed-off-by: Louis Li 
Reviewed-by: Christian König 
Signed-off-by: Alex Deucher 
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman

drm/amd/display: Add ASICREV_IS_PICASSO

2019-06-11T10:19:21+00:00

commit ada637e70f96862ff5ba20a169506b58cf567db9 upstream.

[WHY]
We only want to load DMCU FW on Picasso and Raven 2, not on Raven 1.

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

drm/amdgpu/soc15: skip reset on init

2019-06-11T10:19:21+00:00

commit 5887a59961e2295c5b02f39dbc0ecf9212709b7b upstream.

Not necessary on soc15 and breaks driver reload on server cards.

Acked-by: Amber Lin 
Signed-off-by: Alex Deucher 
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman

drm/amdgpu: remove ATPX_DGPU_REQ_POWER_FOR_DISPLAYS check when hotplug-in

2019-06-11T10:19:21+00:00

commit bdb1ccb080dafc1b4224873a5b759ff85a7d1c10 upstream.

In amdgpu_atif_handler, when hotplug event received, remove
ATPX_DGPU_REQ_POWER_FOR_DISPLAYS check. This bit's check will cause missing
system resume.

Signed-off-by: Aaron Liu 
Reviewed-by: Alex Deucher 
Signed-off-by: Alex Deucher 
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman

drm/amdgpu/psp: move psp version specific function pointers to early_init

2019-06-11T10:19:20+00:00

commit 9d6fea5744d6798353f37ac42a8a653a2607ca69 upstream.

In case we need to use them for GPU reset prior initializing the
asic.  Fixes a crash if the driver attempts to reset the GPU at driver
load time.

Acked-by: Christian König 
Signed-off-by: Alex Deucher 
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman

drm/amd/display: Reset planes that were disabled in init_pipes

2019-05-31T13:43:58+00:00

[ Upstream commit 4bc46da4a3aeeb4d55e83dd276cf72756e908286 ]

[Why]
Seamless boot tries to reuse planes that were enabled for the first
commit applied.

In the case where Raven is booting with two monitors connected and the
first commit contains two streams the screen corruption would occur
because the second stream was trying to re-use a tg and plane that
weren't previously enabled.

The state on the first commit looks something like the following:

TG0: enabled=1
TG1: enabled=0
TG2: enabled=0
TG3: enabled=0

New state: pipe=0, stream=0,    plane=0,       new_tg=0
New state: pipe=1, stream=1,    plane=1,       new_tg=1
New state: pipe=2, stream=NULL, plane=NULL,    new_tg=NULL
New state: pipe=3, stream=NULL, plane=NULL,    new_tg=NULL

Only one plane/tg is setup before we enter accelerated mode so
we really want to disabling everything but that first plane.

[How]

Check if the stream is not NULL and if the tg is enabled before
deciding whether to skip the plane disable.

Also ensure we're also disabling on the current state's pipe_ctx so
we don't overwrite the fields in the new pending state.

Signed-off-by: Nicholas Kazlauskas 
Reviewed-by: Anthony Koo 
Acked-by: Harry Wentland 
Acked-by: Leo Li 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin

drm/amd/display: Fix exception from AUX acquire failure

2019-05-31T13:43:58+00:00

[ Upstream commit dcf1a988678e2e39ce2b4115b8ce14d208c8c481 ]

[Why]
AUX arbitration occurs between SW and FW components.
When AUX acquire fails, it causes engine->ddc to be NULL,
which leads to an exception when we try to release the AUX
engine.

[How]
When AUX engine acquire fails, it should return from the
function without trying to continue the operation.
The upper level will determine if it wants to retry.
i.e. dce_aux_transfer_with_retries will be used and retry.

Signed-off-by: Anthony Koo 
Reviewed-by: Aric Cyr 
Acked-by: Leo Li 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin

drm/amd/display: Set stream->mode_changed when connectors change

2019-05-31T13:43:53+00:00

[ Upstream commit b9952f93cd2cf5fca82b06a8179c0f5f7b769e83 ]

[Why]
The kms_plane@plane-position-covered-pipe-*-planes subtests can produce
a sequence of atomic commits such that neither active_changed nor
mode_changed but connectors_changed.

When this happens we remove the old stream from the context and add
a new stream but the new stream doesn't have mode_changed=true set.

This incorrect programming sequence causes CRC mismatches to occur in
the test.

The stream->mode_changed value should be set whenever a new stream
is created.

[How]
A new stream is created whenever drm_atomic_crtc_needs_modeset is true.
We previously covered the active_changed and mode_changed conditions
for the CRTC but connectors_changed is also checked within
drm_atomic_crtc_needs_modeset.

So just use drm_atomic_crtc_needs_modeset directly to determine the
mode_changed flag.

Signed-off-by: Nicholas Kazlauskas 
Reviewed-by: Sun peng Li 
Acked-by: Bhawanpreet Lakha 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin

drm/amd/display: half bandwidth for YCbCr420 during validation

2019-05-31T13:43:53+00:00

[ Upstream commit 162f807858d15bde60cf373a3ad46e03200ad9d8 ]

[Why]
used to be unable to run 4:2:0 if using a dongle because 4k60 bandwidth
exceeded dongle caps

[How]
half pixel clock during comparison to dongle cap. *Could get stuck on black
screen on monitor that don't support 420 but will be selecting 420 as
preferred mode*

Signed-off-by: Martin Leung 
Reviewed-by: Wenjing Liu 
Acked-by: Aidan Wood 
Acked-by: Bhawanpreet Lakha 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin