[Intel-gfx] [PATCH] drm/i915/huc: Add more errors for I915_PARAM_HUC_STATUS

[Chris Wilson]

Quoting Michal Wajdeczko (2020-03-30 15:02:53)
> 
> 
> On 30.03.2020 14:28, Chris Wilson wrote:
> > There's nothing else between us loading the fw and the huc rejecting
> > it?
> > 
> > FIRMWARE_FAIL? That's set as the opposite of FIRMWARE_TRANSFERRED in
> > that we failed to upload the image to the HW. The firmware itself hasn't
> > had a chance to run.
> > 
> > case INTEL_UC_FIRMWARE_FAIL:
> >       return -ENXIO;
> > 
> > Or is that being overridden to FIRMWARE_ERROR?
> 
> No, it's not overridden by FIRMWARE_ERROR (since we use FIRMWARE_ERROR
> as final state, while with FIRMWARE_FAIL there is a chance for recovery
> during reset)
> 
> Also note that FIRMWARE_FAIL case is covered by the register check that
> we have below, which provides HuC runtime status.

Yes, if it only reports on the auth failure.

> And if we decide to use FIRMWARE_FAIL to report -ENXIO, then it is
> unlikely that we will ever report 0 again for any other fw error that
> could prevent fw from successful load (now recall your and Joonas
> position that this param shall stay as reflection of register read).
> 
> Michal
> 
> ps. on other hand, if we trust our uc_fw_status() then we can drop that
> register read, finally decouple GET_PARAM from MMIO_READ and fully rely
> on cached status:

imo, that register read is the icing on the cake. We can tell whether
the FW got to the HW, but we can't tell if the HW was truly happy with
the FW without asking it.

I look at it as exposing an interface for the final capability bits to
userspace that the kernel does not have to understand, that go above and
beyond the kernel loading the firmware and confirming execution.
-Chris