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

drm/amd/display: If one stream full updates, full update all planes

2019-05-16T17:40:19+00:00

[ Upstream commit c238bfe0be9ef7420f7669a69e27c8c8f4d8a568 ]

[Why]
On some compositors, with two monitors attached, VT terminal
switch can cause a graphical issue by the following means:

There are two streams, one for each monitor. Each stream has one
plane

current state:
	M1:S1->P1
	M2:S2->P2

The user calls for a terminal switch and a commit is made to
change both planes to linear swizzle mode. In atomic check,
a new dc_state is constructed with new planes on each stream

new state:
	M1:S1->P3
	M2:S2->P4

In commit tail, each stream is committed, one at a time. The first
stream (S1) updates properly, triggerring a full update and replacing
the state

current state:
	M1:S1->P3
	M2:S2->P4

The update for S2 comes in, but dc detects that there is no difference
between the stream and plane in the new and current states, and so
triggers a fast update. The fast update does not program swizzle,
so the second monitor is corrupted

[How]
Add a flag to dc_plane_state that forces full updates

When a stream undergoes a full update, set this flag on all changed
planes, then clear it on the current stream

Subsequent streams will get full updates as a result

Signed-off-by: David Francis 
Signed-off-by: Nicholas Kazlauskas 
Reviewed-by: Roman Li 
Acked-by: Bhawanpreet Lakha 
Acked-by: Nicholas Kazlauskas 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin

drm/amdgpu: shadow in shadow_list without tbo.mem.start cause page fault in sriov TDR

2019-05-16T17:40:17+00:00

[ Upstream commit b575f10dbd6f84c2c8744ff1f486bfae1e4f6f38 ]

shadow was added into shadow_list by amdgpu_bo_create_shadow.
meanwhile, shadow->tbo.mem was not fully configured.
tbo.mem would be fully configured by amdgpu_vm_sdma_map_table until calling amdgpu_vm_clear_bo.
If sriov TDR occurred between amdgpu_bo_create_shadow and amdgpu_vm_sdma_map_table,
amdgpu_device_recover_vram would deal with shadow without tbo.mem.start.

Signed-off-by: Wentao Lou 
Reviewed-by: Christian König 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin

drm/amd/display: extending AUX SW Timeout

2019-05-16T17:40:16+00:00

[ Upstream commit f4bbebf8e7eb4d294b040ab2d2ba71e70e69b930 ]

[Why]
AUX takes longer to reply when using active DP-DVI dongle on some asics
resulting in up to 2000+ us edid read (timeout).

[How]
1. Adjust AUX poll to match spec
2. Extend the SW timeout. This does not affect normal
operation since we exit the loop as soon as AUX acks.

Signed-off-by: Martin Leung 
Reviewed-by: Jun Lei 
Acked-by: Joshua Aberback 
Acked-by: Leo Li 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin

drm/amd/display: fix cursor black issue

2019-05-10T16:36:09+00:00

[ Upstream commit c1cefe115d1cdc460014483319d440b2f0d07c68 ]

[Why]
the member sdr_white_level of struct dc_cursor_attributes was not
initialized, then the random value result that
dcn10_set_cursor_sdr_white_level() set error hw_scale value 0x20D9(normal
value is 0x3c00), this cause the black cursor issue.

[how]
just initilize the obj of struct dc_cursor_attributes to zero to avoid
the random value.

Reviewed-by: Nicholas Kazlauskas 
Signed-off-by: Tianci Yin 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin

drm/amdgpu: amdgpu_device_recover_vram always failed if only one node in shadow_list

2019-05-10T16:36:09+00:00

[ Upstream commit 1712fb1a2f6829150032ac76eb0e39b82a549cfb ]

amdgpu_bo_restore_shadow would assign zero to r if succeeded.
r would remain zero if there is only one node in shadow_list.
current code would always return failure when r <= 0.
restart the timeout for each wait was a rather problematic bug as well.
The value of tmo SHOULD be changed, otherwise we wait tmo jiffies on each loop.

Signed-off-by: Wentao Lou 
Reviewed-by: Christian König 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin

drm/amdgpu: Adjust IB test timeout for XGMI configuration

2019-05-10T16:36:09+00:00

[ Upstream commit d4162c61e253177936fcfe6c29f7b224d9a1efb8 ]

On XGMI configuration the ib test may take longer to finish

Signed-off-by: shaoyunl 
Reviewed-by: Christian König 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin

drm/amdkfd: Add picasso pci id

2019-05-10T16:36:08+00:00

[ Upstream commit e7ad88553aa1d48e950ca9a4934d246c1bee4be4 ]

Picasso is a new raven variant.

Reviewed-by: Kent Russell 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin

drm/amdgpu/gmc9: fix VM_L2_CNTL3 programming

2019-04-27T07:37:42+00:00

commit 1925e7d3d4677e681cc2e878c2bdbeaee988c8e2 upstream.

Got accidently dropped when 2+1 level support was added.

Fixes: 6a42fd6fbf534096 ("drm/amdgpu: implement 2+1 PD support for Raven v3")
Reviewed-by: Christian König 
Signed-off-by: Alex Deucher 
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman

drm/amdkfd: use init_mqd function to allocate object for hid_mqd (CI)

2019-04-20T07:17:04+00:00

[ Upstream commit cac734c2dbd2514f14c8c6a17caba1990d83bf1d ]

if use the legacy method to allocate object, when mqd_hiq need to run
uninit code, it will be cause WARNING call trace.

eg: (s3 suspend test)
[   34.918944] Call Trace:
[   34.918948]  [] dump_stack+0x19/0x1b
[   34.918950]  [] __warn+0xd8/0x100
[   34.918951]  [] warn_slowpath_null+0x1d/0x20
[   34.918991]  [] uninit_mqd_hiq_sdma+0x4e/0x50 [amdgpu]
[   34.919028]  [] uninitialize+0x37/0xe0 [amdgpu]
[   34.919064]  [] kernel_queue_uninit+0x16/0x30 [amdgpu]
[   34.919086]  [] pm_uninit+0x12/0x20 [amdgpu]
[   34.919107]  [] stop_nocpsch+0x15/0x20 [amdgpu]
[   34.919129]  [] kgd2kfd_suspend.part.4+0x2e/0x50 [amdgpu]
[   34.919150]  [] kgd2kfd_suspend+0x17/0x20 [amdgpu]
[   34.919171]  [] amdgpu_amdkfd_suspend+0x1a/0x20 [amdgpu]
[   34.919187]  [] amdgpu_device_suspend+0x88/0x3a0 [amdgpu]
[   34.919189]  [] ? enqueue_entity+0x2ef/0xbe0
[   34.919205]  [] amdgpu_pmops_suspend+0x20/0x30 [amdgpu]
[   34.919207]  [] pci_pm_suspend+0x6f/0x150
[   34.919208]  [] ? pci_pm_freeze+0xf0/0xf0
[   34.919210]  [] dpm_run_callback+0x46/0x90
[   34.919212]  [] __device_suspend+0xfb/0x2a0
[   34.919213]  [] async_suspend+0x1f/0xa0
[   34.919214]  [] async_run_entry_fn+0x3f/0x130
[   34.919216]  [] process_one_work+0x17f/0x440
[   34.919217]  [] worker_thread+0x126/0x3c0
[   34.919218]  [] ? manage_workers.isra.25+0x2a0/0x2a0
[   34.919220]  [] kthread+0xd1/0xe0
[   34.919221]  [] ? insert_kthread_work+0x40/0x40
[   34.919222]  [] ret_from_fork_nospec_begin+0x7/0x21
[   34.919224]  [] ? insert_kthread_work+0x40/0x40
[   34.919224] ---[ end trace 38cd9f65c963adad ]---

Signed-off-by: Kevin Wang 
Reviewed-by: Oak Zeng 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin

drm/amdgpu: psp_ring_destroy cause psp->km_ring.ring_mem NULL

2019-04-20T07:17:03+00:00

[ Upstream commit 14d20ec7f31ef96a2e7dcf7880b13dde1d473b56 ]

psp_ring_destroy inside psp_load_fw cause psp->km_ring.ring_mem NULL.
Call Trace occurred when psp_cmd_submit.
should be psp_ring_stop instead.

Reviewed-by: Xiangliang Yu 
Signed-off-by: Wentao Lou 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin