Re: [08/11] drm/i915/guc: Wait for doorbell to be inactive before deallocating

[Oscar Mateo <oscar.mateo@intel.com>]

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