On 2018-07-20 09:58 AM, S, Shirish wrote:
> Sure Michel, but not immediately.
> Is that fine?
Sure, thanks.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
On 2018-07-19 11:20 AM, Michel Dänzer wrote:
>
> 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
>
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.
[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.
[How]
This patch restructures the console_lock,
