On Fri, 24 May 2019 15:29:22 +0200, Michal Wajdeczko
wrote:
On Fri, 24 May 2019 15:10:58 +0200, Joonas Lahtinen
wrote:
Quoting Ye, Tony (2019-05-22 14:32:41)
From UMD perspective, when HuC is not working as expected, usually we
look into the kernel log and i915_huc_load_status debugfs
On Fri, 24 May 2019 15:10:58 +0200, Joonas Lahtinen
wrote:
Quoting Ye, Tony (2019-05-22 14:32:41)
From UMD perspective, when HuC is not working as expected, usually we
look into the kernel log and i915_huc_load_status debugfs to find out
why it's not working. It will be helpful to know the
Quoting Ye, Tony (2019-05-22 14:32:41)
> From UMD perspective, when HuC is not working as expected, usually we
> look into the kernel log and i915_huc_load_status debugfs to find out
> why it's not working. It will be helpful to know the reason of the
> failure from the error code. The typicall
On 5/21/2019 7:08 PM, Michal Wajdeczko wrote:
On Tue, 21 May 2019 13:04:12 +0200, Ye, Tony wrote:
There are two users of I915_PARAM_HUC_STATUS, the intel-media driver
and the legacy intel-vaapi-driver.
Both drivers check the return value like this:
has_huc = !! ret_value;
So the ABI
On Tue, 21 May 2019 13:04:12 +0200, Ye, Tony wrote:
There are two users of I915_PARAM_HUC_STATUS, the intel-media driver and
the legacy intel-vaapi-driver.
Both drivers check the return value like this:
has_huc = !! ret_value;
So the ABI change will break the existing stack because ne
There are two users of I915_PARAM_HUC_STATUS, the intel-media driver and
the legacy intel-vaapi-driver.
Both drivers check the return value like this:
has_huc = !! ret_value;
So the ABI change will break the existing stack because negative values
are treated as 1, won't it?
On 5/20/2019
On Mon, 20 May 2019 12:44:43 +0200, Chris Wilson
wrote:
Quoting Michal Wajdeczko (2019-05-20 11:24:37)
On Mon, 20 May 2019 11:35:26 +0200, Chris Wilson
wrote:
> Quoting Michal Wajdeczko (2019-05-19 22:50:43)
>> If we never attempted to load HuC firmware, or we already wedged
>> or reset Gu
Quoting Michal Wajdeczko (2019-05-20 11:24:37)
> On Mon, 20 May 2019 11:35:26 +0200, Chris Wilson
> wrote:
>
> > Quoting Michal Wajdeczko (2019-05-19 22:50:43)
> >> If we never attempted to load HuC firmware, or we already wedged
> >> or reset GuC/HuC, then there is no reason to wake up the dev
On Mon, 20 May 2019 11:35:26 +0200, Chris Wilson
wrote:
Quoting Michal Wajdeczko (2019-05-19 22:50:43)
If we never attempted to load HuC firmware, or we already wedged
or reset GuC/HuC, then there is no reason to wake up the device
to check one bit in the register that will be for sure clear
Quoting Michal Wajdeczko (2019-05-19 22:50:43)
> If we never attempted to load HuC firmware, or we already wedged
> or reset GuC/HuC, then there is no reason to wake up the device
> to check one bit in the register that will be for sure cleared.
>
> v2: check if HuC was enabled; subtle change in A
If we never attempted to load HuC firmware, or we already wedged
or reset GuC/HuC, then there is no reason to wake up the device
to check one bit in the register that will be for sure cleared.
v2: check if HuC was enabled; subtle change in ABI
reuse hus_is_load helper
Suggested-by: Chris Wils
11 matches
Mail list logo
