On 7/18/2018 3:30 PM, Michel Dänzer wrote:
> 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.
Ok, in the next patch-set i have not moved amdgpu_fbdev_set_suspend()
Regards,
Shirish S
--
Regards,
Shirish S
