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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





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@xxxxxxxxx>
Cc: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
Cc: Joonas Lahtinen <joonas.lahtinen@xxxxxxxxxxxxxxx>
Cc: Sagar Arun Kamble <sagar.a.kamble@xxxxxxxxx>
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

_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux