On 26/02/18 23:50, Chris Wilson wrote:
Quoting Sagar Arun Kamble (2018-02-27 06:54:46)
On 2/27/2018 2:22 AM, Chris Wilson wrote:
Quoting Daniele Ceraolo Spurio (2018-02-26 16:57:11)
As you said we do always reset GuC no matter the value of the modparam,
but that does not reset the doorbell HW. If we're coming out of S3 and
the state as been preserved this will cause the doorbell HW to be left
in an unclean state, which could cause spurious doorbell interrupts to
be sent to GuC, not sure how the firmware handles those. The code as
moved since last time I looked at this in detail and I think we're now
most likely going to overwrite those unclean doorbells, but there are
unlikely corner cases (preempt context failing to be created) where we
might not do so.
I'm still going "wait, we can put the device into D3 and the GuC is
still powered?" Something feels wrong if the GuC retains state after the
HW is powered down.
GuC will be powered down, with RC6. Just that firmware in WOPCM can get
wiped off if
memory is reset/powered down during resume. In case of mem sleep
generally WOPCM stays intact and if we exit
RC6 on resume from sleep, firmware will be restored into GuC without
driver intervention.
But since we do full GPU reset as part of sanitize we have to load it
from driver again.
On resume, we don't know if we are coming from module load, resume from
S3, resume S3+RST, resume from S4, or resume from kexec. (S3+RST, kexec
are truly without our knowledge, the others we could feed the
information through but RST makes that moot.) Ergo, you cannot know if
the right fw image is loaded and aiui you should treat the state as
undefined and always reload. Does that make sense? Is there a way you
can query what fw is loaded and so skip instead?
-Chris
Not sure if there is already a way to query the FW version, but we could
ask for a new H2G to be added if there isn't. However, even if the
firmware version matches, if we can't confirm it is exactly the one we
loaded (and not a reload of the same version) there is no guarantee that
its internal state is what we expect. Also, we would have to stop doing
full gpu resets around suspend/resume which I doubt it is something we want.
Daniele
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
