On 17/09/2019 19:29, Daniele Ceraolo Spurio wrote:
On 9/17/2019 3:22 AM, Tvrtko Ursulin wrote:
On 16/09/2019 22:41, Daniele Ceraolo Spurio wrote:
Our assumption that the we can ask the HW to lock the SFC even if not
currently in use does not match the HW commitment. The expectation from
On 9/17/2019 12:49 PM, Chris Wilson wrote:
Quoting Daniele Ceraolo Spurio (2019-09-17 20:45:02)
On 9/17/2019 11:57 AM, Chris Wilson wrote:
Quoting Daniele Ceraolo Spurio (2019-09-17 19:36:35)
On 9/17/2019 12:57 AM, Chris Wilson wrote:
Quoting Daniele Ceraolo Spurio (2019-09-16 22:41:04)
Quoting Daniele Ceraolo Spurio (2019-09-17 20:45:02)
>
>
> On 9/17/2019 11:57 AM, Chris Wilson wrote:
> > Quoting Daniele Ceraolo Spurio (2019-09-17 19:36:35)
> >>
> >> On 9/17/2019 12:57 AM, Chris Wilson wrote:
> >>> Quoting Daniele Ceraolo Spurio (2019-09-16 22:41:04)
> Our assumption
On 9/17/2019 11:57 AM, Chris Wilson wrote:
Quoting Daniele Ceraolo Spurio (2019-09-17 19:36:35)
On 9/17/2019 12:57 AM, Chris Wilson wrote:
Quoting Daniele Ceraolo Spurio (2019-09-16 22:41:04)
Our assumption that the we can ask the HW to lock the SFC even if not
currently in use does not
Quoting Daniele Ceraolo Spurio (2019-09-17 19:36:35)
>
>
> On 9/17/2019 12:57 AM, Chris Wilson wrote:
> > Quoting Daniele Ceraolo Spurio (2019-09-16 22:41:04)
> >> Our assumption that the we can ask the HW to lock the SFC even if not
> >> currently in use does not match the HW commitment. The
On 9/17/2019 12:57 AM, Chris Wilson wrote:
Quoting Daniele Ceraolo Spurio (2019-09-16 22:41:04)
Our assumption that the we can ask the HW to lock the SFC even if not
currently in use does not match the HW commitment. The expectation from
the HW is that SW will not try to lock the SFC if the
On 9/17/2019 3:22 AM, Tvrtko Ursulin wrote:
On 16/09/2019 22:41, Daniele Ceraolo Spurio wrote:
Our assumption that the we can ask the HW to lock the SFC even if not
currently in use does not match the HW commitment. The expectation from
the HW is that SW will not try to lock the SFC if the
Quoting Daniele Ceraolo Spurio (2019-09-16 22:41:04)
> @@ -401,7 +407,10 @@ static void gen11_unlock_sfc(struct intel_engine_cs
> *engine)
> return;
> }
>
> - rmw_clear_fw(uncore, sfc_forced_lock, sfc_forced_lock_bit);
> + lock = intel_uncore_read_fw(uncore,
On 16/09/2019 22:41, Daniele Ceraolo Spurio wrote:
Our assumption that the we can ask the HW to lock the SFC even if not
currently in use does not match the HW commitment. The expectation from
the HW is that SW will not try to lock the SFC if the engine is not
using it and if we do that the
Quoting Daniele Ceraolo Spurio (2019-09-16 22:41:04)
> Our assumption that the we can ask the HW to lock the SFC even if not
> currently in use does not match the HW commitment. The expectation from
> the HW is that SW will not try to lock the SFC if the engine is not
> using it and if we do that
Our assumption that the we can ask the HW to lock the SFC even if not
currently in use does not match the HW commitment. The expectation from
the HW is that SW will not try to lock the SFC if the engine is not
using it and if we do that the behavior is undefined; on ICL the HW
ends up to returning
11 matches
Mail list logo
