On 2018-07-18 11:40 AM, Shirish S wrote:
> [Why]
> 1. To ensure that resume path reciprocates the sequence followed during
> suspend.
> 2. 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.
>
> [How]
> This patch restructures the console_lock, console_unlock around
> amdgpu_fbdev_set_suspend() and moves this new block to the very beginning
> of the resume sequence.
>
> Signed-off-by: Shirish S <shirish.s at amd.com>
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 12 ++++--------
> 1 file changed, 4 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index 709e4a3..fc4c517 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -2720,8 +2720,11 @@ int amdgpu_device_resume(struct drm_device *dev, bool resume, bool fbcon)
> if (dev->switch_power_state == DRM_SWITCH_POWER_OFF)
> return 0;
>
> - if (fbcon)
> + if (fbcon) {
> console_lock();
> + amdgpu_fbdev_set_suspend(adev, 0);
> + console_unlock();
> + }
>
> if (resume) {
> pci_set_power_state(dev->pdev, PCI_D0);
I don't think the amdgpu_fbdev_set_suspend call can be moved before the
pci_set_power_state call, because fbcon may presumably try writing to
the device's VRAM at any point after amdgpu_fbdev_set_suspend.
There might be other things that need to happen before
amdgpu_fbdev_set_suspend.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
