On 2018-07-18 12:24 PM, Shirish S wrote: > [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. Maybe this could be clarified that the concern is about consoles other than fbcon on this device, e.g. a serial console. > @@ -2746,7 +2743,6 @@ int amdgpu_device_resume(struct drm_device *dev, bool resume, bool fbcon) > > amdgpu_fence_driver_resume(adev); > > - > r = amdgpu_device_ip_late_init(adev); > if (r) > goto unlock; Drop this hunk. With the above fixed, Reviewed-by: Michel Dänzer <michel.daenzer at amd.com> Possible follow-up work: * Move the console_(un)lock calls into amdgpu_fbdev_set_suspend, or maybe use drm_fb_helper_set_suspend_unlocked instead of locking ourselves * Move the amdgpu_fbdev_set_suspend call in amdgpu_device_suspend further up, at least before the pci_set_power_state call. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
