Re: [PATCH 3/3] drm/radeon: uvd/vce properly pin/unpin firmware accross suspend/resume.

["Christian König" <deathsimple@vodafone.de>]

Am 16.03.2016 um 13:35 schrieb Jerome Glisse:
> On Wed, Mar 16, 2016 at 1:10 PM, Christian König
> <christian.koenig@amd.com> wrote:
>> Am 16.03.2016 um 12:56 schrieb jglisse@redhat.com:
>>> From: Jérome Glisse <jglisse@redhat.com>
>>>
>>> We need to unpin on suspend and pin on resume. This shuffle code around
>>> to do just that.
>>>
>>> Signed-off-by: Jérôme Glisse <jglisse@redhat.com>
>>> Cc: Alex Deucher <alexander.deucher@amd.com>
>>> Cc: Christian König <christian.koenig@amd.com>
>>
>> NAK, that won't work correctly.
>>
>> When the firmware is loaded at one location once you can't move it without
>> power cycling the ASIC.
>>
>> That only works when you completely shut down the system, but not if you
>> just suspend to memory on an APU or do a test cycle without actually power
>> down.
>>
>> We already tried this approach and it took me month to figure out what's
>> going wrong when the firmware end up at a different location after the
>> driver started again.
>>
>> Regards,
>> Christian.
> Well that exactly what happens on hibernation. The firmware keycheck
> is failing and vce breaks. I have been trying to make it works but
> even putting it at same location is not enough. This is only an issue
> with hibernation, and module load/unload, suspend is fine as hw is
> powercycle. So this patch will not break anything that does already
> work. It only make code follow what other part of the code does.

Take a look at the history of the UVD code. We already had it this way 
and changed it because that fixed suspend/resume for a lot of people.

Additional to that keeping the firmware at the same location is the 
documented behavior how the hardware should be programmed.

For Amdgpu Leo even had it working that UVD sessions survive a 
suspend/resume cycle, but we haven't dared to enable that for everything 
again because of all the problems testing it.

Regards,
Christian.

>
> Cheers,
> Jérôme
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel