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

[Michal Wajdeczko <michal.wajdeczko@intel.com>]

On 30.03.2020 16:12, Chris Wilson wrote:
> 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.

note that kernel already asked HW in intel_huc_auth() for FW status and
based on that info changed our cached fw status to RUNNING if and only
if HW was happy with that FW (and that shall not change until reset)

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