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
__
Sure Michel, but not immediately.
Is that fine?
Regards,
Shirish S
-Original Message-
From: Michel Dänzer [mailto:mic...@daenzer.net]
Sent: Friday, July 20, 2018 1:04 PM
To: S, Shirish
Cc: amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amdgpu: lock and unlock console only for
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
> fu
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.
May
[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, consol
