linux/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c, branch v4.19

drm/amdgpu: move PSP init prior to IH in gpu reset

2018-09-11T03:58:21Z

since we use PSP to program IH regs now Signed-off-by: Monk Liu Acked-by: Christian König Reviewed-by: Huang Rui Signed-off-by: Emily Deng Signed-off-by: Alex Deucher

Revert "drm/amdgpu/display: Replace CONFIG_DRM_AMD_DC_DCN1_0 with CONFIG_X86"

2018-08-21T19:32:28Z

This reverts commit 8624c3c4dbfe24fc6740687236a2e196f5f4bfb0. We need CONFIG_DRM_AMD_DC_DCN1_0 to guard code that is using fp math. Acked-by: Alex Deucher Reviewed-by: Michel Dänzer Signed-off-by: Leo (Sunpeng) Li Signed-off-by: Alex Deucher

Merge branch 'drm-next-4.19' of git://people.freedesktop.org/~agd5f/linux into drm-next

2018-08-10T01:43:02Z

More fixes for 4.19: - Fixes for scheduler - Fix for SR-IOV - Fixes for display Signed-off-by: Dave Airlie From: Alex Deucher Link: https://patchwork.freedesktop.org/patch/msgid/20180809200052.2777-1-alexander.deucher@amd.com

drm/amdgpu/sriov: give 8s for recover vram under RUNTIME

2018-08-09T16:59:17Z

Extend the timeout for recovering vram bos from shadows on sr-iov to cover the worst case scenario for timeslices and VFs Under runtime, the wait fence time could be quite long when other VFs are in exclusive mode. For example, for 4 VF, every VF's exclusive timeout time is set to 3s, then the worst case is 9s. If the VF number is more than 4,then the worst case time will be longer. The 8s is the test data, with setting to 8s, it will pass the TDR test for 1000 times. SWDEV-161490 Signed-off-by: Monk Liu Signed-off-by: Emily Deng Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher

BackMerge v4.18-rc7 into drm-next

2018-07-30T00:39:22Z

rmk requested this for armada and I think we've had a few conflicts build up. Signed-off-by: Dave Airlie

drm/amdgpu: move the amdgpu_fbdev_set_suspend() further up

2018-07-24T20:14:54Z

This patch moves amdgpu_fbdev_set_suspend() to the beginning of suspend sequence. This is to ensure fbcon does not to write to the VRAM after GPU is powerd down. Signed-off-by: Shirish S Reviewed-by: Michel Dänzer Signed-off-by: Alex Deucher

drm/amdgpu: rework suspend and resume to deal with atomic changes

2018-07-20T19:24:55Z

Use the newly split ip suspend functions to do suspend displays first (to deal with atomic so that FBs can be unpinned before attempting to evict vram), then evict vram, then suspend the other IPs. Also move the non-DC pinning code to only be called in the non-DC cases since atomic should take care of DC. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107065 Fixes: e00fb85 drm: Stop updating plane->crtc/fb/old_fb on atomic drivers Acked-by: Harry Wentland Reviewed-and-tested-by: Andrey Grodzovsky Signed-off-by: Alex Deucher

drm/amdgpu: split ip suspend into 2 phases

2018-07-20T19:24:50Z

We need to do some IPs earlier to deal with ordering issues similar to how resume is split into two phases. Do DCE first to deal with atomic, then do the rest. Acked-by: Harry Wentland Reviewed-and-tested-by: Andrey Grodzovsky Signed-off-by: Alex Deucher

drm/amdgpu: use drm_fb helper for console_(un)lock

2018-07-20T19:24:18Z

This patch removes the usage of console_(un)lock by replacing drm_fb_helper_set_suspend() to drm_fb_helper_set_suspend_unlocked() which locks and unlocks the console instead of locking ourselves. Signed-off-by: Shirish S Reviewed-by: Michel Dänzer Signed-off-by: Alex Deucher

drm/amdgpu: lock and unlock console only for amdgpu_fbdev_set_suspend [V5]

2018-07-20T19:23:33Z

[Why] While the console_lock is held, console output will be buffered, till its unlocked it wont be emitted, hence its ideal to unlock sooner to enable debugging/detecting/fixing of any issue in the remaining sequence of events in resume path. The concern here is about consoles other than fbcon on the device, e.g. a serial console [How] This patch restructures the console_lock, console_unlock around amdgpu_fbdev_set_suspend() and moves this new block appropriately. V2: Kept amdgpu_fbdev_set_suspend after pci_set_power_state V3: Updated the commit message to clarify the real concern that this patch addresses. V4: code clean-up. V5: fixed return value Signed-off-by: Shirish S Reviewed-by: Michel Dänzer Signed-off-by: Alex Deucher