On 03/13/2017 04:46 AM, Chris Wilson wrote:
On Fri, Mar 10, 2017 at 08:28:55AM -0800, Oscar Mateo wrote:
Doorbell release flow requires that we wait for GEN8_DRB_VALID bit to go
to zero after updating db_status before we call the GuC to release the
doorbell.
Does this fix some of the '110' errors?
-Chris
No, AFAICT this doesn't fix anything (but it's required nonetheless).
The 110 errors (ENTER_S_STATE and DEALLOCATE_DOORBELL failed calls to
GuC) are cause by us resetting the GuC right before we ask it to do
something. E.g.: in the suspend path, we do
i915_gem_suspend()->i915_gem_sanitize()->intel_gpu_reset() and then
intel_guc_suspend() inmediately after. After the sanitize, the GuC is in
reset state and without a firmware loaded, so asking it to suspend is
pretty useless. Same thing when trying to orderly shutdown the doorbells
right after reset (the GuC has no idea of what doorbell we are talking
about).
For now, the simple fix would be to keep doing the reset and not ask the
GuC to do anything after. But sooner or later, we won't be able to get
away with this. E.g.: if we enable direct submission, the GuC is the
only one that will know about all the requests in-flight, and therefore
the only one that can decide when to suspend. Also, surely loading the
GuC firmware every time is slowing down the resume path by a lot?
-- Oscar
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
