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

[Michal Wajdeczko]

On Fri, 01 Dec 2017 16:55:41 +0100, Sagar Arun Kamble  
<sagar.a.kamble at intel.com> wrote:

>
>
> 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.

if we return 0 and use execlist then we will have mismatched state
in flags as USES_GUC will be still returning true (as the same time
we don't want to do late changes to enable_guc modparam on failure
as part of the driver was already initiated with old value)