drm/amdgpu: value of amdgpu_sriov_vf cannot be set into F32_POLL_ENABLE
amdgpu_sriov_vf would return 0x0 or 0x4 to indicate if sriov.
but F32_POLL_ENABLE need 0x0 or 0x1 to determine if enabled.
set 0x4 into F32_POLL_ENABLE would make SDMA0_GFX_RB_WPTR_POLL_CNTL not working.
drm/amdgpu: amdgpu_device_recover_vram got NULL of shadow->parent
amdgpu_bo_destroy had a bug by calling amdgpu_bo_unref outside mutex_lock.
If amdgpu_device_recover_vram executed between amdgpu_bo_unref and list_del_init,
it would get NULL of shadow->parent, then caused Call Trace and GPU reset failed.
Change-Id: I41d7b54605e613e87ee03c3ad89c191063c19230
Signed-off-by: Wentao Lou <email address hidden>
Reviewed-by: Christian König <email address hidden>
drm/amdgpu: shadow in shadow_list without tbo.mem.start cause page fault in sriov TDR
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.
Change-Id: I1a6a69587d6c689d0a357dd495ee44833d0f0790
Signed-off-by: Wentao Lou <email address hidden>
Reviewed-by: Christian König <email address hidden>
amdgpu_device_recover_vram always failed if only one node in shadow_list
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.
Change-Id: I7e836ec7ab6cd0f069aac24f88e454e906637541
Signed-off-by: Wentao Lou <email address hidden>
Reviewed-by: Christian König <email address hidden>
drm/amdkcl: [RHEL7_4] fix display build error on redhat 7.4
[Why]
On redhat 7.4,its drm version is 4.10.0.So there will these build errors
on redhat 7.4
1.for_each_oldnew_plane_in_state build error
2.dm_atomic_get_state,dm_atomic_get_old_state build error
For these two errors,we can refer to the old kcl in patch:
drm/amd/display: Reformat dm_determine_update_type_for_commit
3.mutex_lock build error
amdgpu_display_manager->dc_lock is not defined before
DRM_VERSION(4,14,0)
[How]
Use the old kcl in patch:
drm/amd/display: Reformat dm_determine_update_type_for_commit
to fix build error 1(for_each_oldnew_plane_in_state) and build error 2
(dm_atomic_get_state,dm_atomic_get_old_state)
Avoid using amdgpu_display_manager->dc_lock before DRM_VERSION(4,14,0)
to fix build error 3(mutex_lock build error)
drm/amdkcl: [RHEL7_4] fix pci_upstream_bridge redefinition build error on redhat 7.4
[Why]
pci_upstream_bridge is defined before kernel version(3.13.0). However,
the function is also defined on redhat hat 7.4,although its kernel is
3.10.0.So there will be redefinition build error when using this
function on redhat 7.4
[How]
Replace OS_NAME_RHEL_7_6 with OS_NAME_RHEL_7_X to avoid redefinition
build error on redhat 7.4
4532132...
by
David Francis <email address hidden>
drm/amd/display: If one stream full updates, full update all planes
[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: Nicholas Kazlauskas <email address hidden>
Signed-off-by: David Francis <email address hidden>
Reviewed-by: Roman Li <email address hidden>
Acked-by: Alex Deucher <email address hidden>
