On 29/03/16 12:48, Daniel Vetter wrote:
On Thu, Mar 24, 2016 at 06:40:15PM +0000, Dave Gordon wrote:
After a suspend-resume cycle, the resumed kernel has no idea what the
booted kernel may have done to the GuC before replacing itself with the
resumed image. In particular, it may have already loaded the GuC with
firmware, which will then cause this kernel's attempt to (re)load the
firmware to fail (GuC program memory is write-once!). The symptoms
(GuC firmware reload fails after hibernation) are further described
in the Bugzilla reference below.
So let's *always* reset the GuC just before (re)loading the firmware;
then the hardware should then be in a well-known state, and we may even
avoid some of the issues arising from unpredictable timing.
Also added some more fields & values to the definition of the GUC_STATUS
register, which is the key diagnostic indicator if the GuC load fails.
Signed-off-by: Dave Gordon <david.s.gordon@xxxxxxxxx>
Reviewed-by: Arun Siluvery <arun.siluvery@xxxxxxxxxxxxxxx>
Cc: Alex Dai <yu.dai@xxxxxxxxx>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94390
I guess both of these should be labelled Cc: stable@xxxxxxxxxxxxxxx when
merging.
-Daniel
Probably not necessary, as the patch to enable GuC loading (and
fallback) by default hasn't yet been merged, so this code isn't reached
unless the (unsafe) kernel parameter is overridden.
.Dave.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
