On Fri, 19 Jul 2019 11:48:43 +0200, Tvrtko Ursulin
<tvrtko.ursulin@xxxxxxxxxxxxxxx> wrote:
From: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx>
It seems absence of GuC fimrware breaks the boot in a bad way:
https://intel-gfx-ci.01.org/tree/drm-tip/Trybot_4640/?
https://intel-gfx-ci.01.org/tree/drm-tip/Trybot_4640/fi-icl-u2/boot0.log
Hmm, for me looks like boot is not prepared to driver probe failure.
I guess this needs to be fixed separately, as CI.BAT **SUCCESS** is
really misleading here https://patchwork.freedesktop.org/series/63931/
Tvrtko Ursulin (2):
Revert "drm/i915/guc: Turn on GuC/HuC auto mode"
Revert "drm/i915: Update description of i915.enable_guc modparam"
Maybe instead of reverting above patches we can just apply two fixes:
1. Ignore HuC firmware fetch/load errors
User space is always relying on HUC_STATUS param so we should really
never treat HuC failures so seriously.
2. Ignore GuC firmware fetch/load errors if GuC submission was not enabled
If we use GuC just to authenticate the HuC, then we can ignore GuC errors,
Later on, once we are closer to re-enabling GuC submission feature, we can
add more patches to change current 'fail on GuC error' behavior:
3. Ignore GuC firmware errors if GuC submission was auto-enabled
We can still fallback to execlist at the cost of some resources lost
for GuC data (but maybe this can be reclaimed as well)
4. Keep driver loaded on GuC fw errors if GuC submission was explicitly
enabled
There was already some approach for that:
https://patchwork.freedesktop.org/series/58294/
just needs some refreshing
Michal
drivers/gpu/drm/i915/i915_params.c | 2 +-
drivers/gpu/drm/i915/i915_params.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
