[Intel-gfx] [PATCH v2 1/1] drm/i915: Suspend GuC prior to GPU Reset during GEM suspend

[Kamble, Sagar A]

On 4/5/2017 6:32 PM, David Weinehall wrote:
> On 2017-04-05 15:54, Joonas Lahtinen wrote:
>> On ke, 2017-04-05 at 15:51 +0530, Sagar Arun Kamble wrote:
>>> i915 is currently doing Full GPU reset at the end of suspend 
>>> followed by
>>> GuC suspend. This reset bypasses the GuC. We need to tell the GuC to
>>> suspend before we do a direct intel_gpu_reset, Otherwise the gpu 
>>> state will
>>> no longer match the GuC's expectations and its suspend will not be
>>> successful. With this change, i915 suspends GuC after suspending GEM 
>>> and
>>> before doing Full GPU reset.
>> + David, Oscar and Michel
>>
>> My understanding is that reloading GuC firmware after each resume is a
>> major bottleneck in resume time, and we instead should be telling GuC
>> to suspend and not reset the GPU, at most only reset the engines.
>>
>> Regards, Joonas
>
> If this is possible, then yes, it'd definitely be preferable. If not,
> then doing the GuC + HuC loading asynchronously on resume would be 
> preferable.
> Anusha mentioned working on asynchronous loading, hence added to CC.
>
>
> Kind regards, David
Data points about GuC load times for reference that I collected today on 
SKL and APL.
At Rpn(lowest frequency) it loads/becomes ready in 3-4 jiffies. Running 
at >=RPe it becomes ready in a jiffy.
Are these times in tolerable limits?
Another concern Daniele highlighted was rare chance of WOPCM persisting 
post suspend/resume and hence needing reload.
I believe the fetch from disk must be time consuming during boot time 
load and for that asynchronous
load can be pursued.