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.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
