On 28/01/2022 21:53, John Harrison wrote:
On 1/28/2022 01:34, Tvrtko Ursulin wrote:
John,
What CI results were used to merge this particular single patch?
Unless I am not seeing it, it was always set in pair with something else.
First with "drm/i915/pmu: Use PM timestamp instead of RING T
On 1/28/2022 01:34, Tvrtko Ursulin wrote:
John,
What CI results were used to merge this particular single patch?
Unless I am not seeing it, it was always set in pair with something else.
First with "drm/i915/pmu: Use PM timestamp instead of RING TIMESTAMP
for reference", which was merged ea
On Fri, Jan 28, 2022 at 09:34:28AM +, Tvrtko Ursulin wrote:
John,
What CI results were used to merge this particular single patch?
Unless I am not seeing it, it was always set in pair with something
else.
First with "drm/i915/pmu: Use PM timestamp instead of RING TIMESTAMP
for referenc
John,
What CI results were used to merge this particular single patch? Unless
I am not seeing it, it was always set in pair with something else.
First with "drm/i915/pmu: Use PM timestamp instead of RING TIMESTAMP for
reference", which was merged earlier in the week and it had a standalone
GuC updates shared memory and KMD reads it. Since this is not
synchronized, we run into a race where the value read is inconsistent.
Sometimes the inconsistency is in reading the upper MSB bytes of the
last_switch_in value. 2 types of cases are seen - upper 8 bits are zero
and upper 24 bits are zer
GuC updates shared memory and KMD reads it. Since this is not
synchronized, we run into a race where the value read is inconsistent.
Sometimes the inconsistency is in reading the upper MSB bytes of the
last_switch_in value. 2 types of cases are seen - upper 8 bits are zero
and upper 24 bits are zer
