[Intel-gfx] [PATCH v2 4/7] drm/i915/uc: Don't use -EIO to report missing firmware

Sagar Arun Kamble sagar.a.kamble at intel.com
Fri Dec 1 15:55:41 UTC 2017



On 12/1/2017 6:01 PM, Chris Wilson wrote:
> Quoting Michal Wajdeczko (2017-12-01 10:33:14)
>> -EIO has special meaning and is used when we want to allow
>> engine initialization to fail and mark GPU as wedged.
>> Missing firmware does not fit into this scenario as this is
>> permanent error not related to GPU condition.
>>
>> Signed-off-by: Michal Wajdeczko <michal.wajdeczko at intel.com>
>> Cc: Chris Wilson <chris at chris-wilson.co.uk>
>> Cc: Joonas Lahtinen <joonas.lahtinen at linux.intel.com>
>> Cc: Sagar Arun Kamble <sagar.a.kamble at intel.com>
> Ok, keeping -EIO to mean something special is a good idea. So if upload
> now fails, we abort loading of the driver with ENOEXEC.
>
> Is that sensible? Let's say due to fs corruption, or other error, we
> aren't able to upload a fw, what should we do? If we abort the driver
> load at this point, the user is likely left with a blank screen. If we
> use -EIO, at least KMS is still functional and the user can still
> interact with the system. (If we just fell back to execlists, then the
> system remains very usable.)
>
> What is the plan for HW initialisation failure?
Earlier we were returning -EIO from intel_uc_init_hw when GuC 
load/submission was "required" (enable_guc_loading/submission=2).
Keeping the same behavior I feel we should return -EIO if (enable_guc & 
1) (need to know that user requested "required")
I feel on auto mode (need to know user requested "auto") falling back to 
execlists makes sense as user dint enforce, so we should be returning 0 
then.
> -Chris



More information about the Intel-gfx mailing list