Re: [Intel-gfx] [PATCH] drm/i915/selftests: Confirm RING_TIMESTAMP / CTX_TIMESTAMP share a clock

From: Chris Wilson <chris@chris-wilson.co.uk>
To: Lionel Landwerlin <lionel.g.landwerlin@intel.com>,
	intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH] drm/i915/selftests: Confirm RING_TIMESTAMP / CTX_TIMESTAMP share a clock
Date: Tue, 11 Aug 2020 16:47:50 +0100	[thread overview]
Message-ID: <159716087083.14054.13900226781053798555@build.alporthouse.com> (raw)
In-Reply-To: <4bab4649-c8b8-45c5-41f5-0f172db79667@intel.com>

Quoting Lionel Landwerlin (2020-08-11 16:37:10)
> On 11/08/2020 12:17, Chris Wilson wrote:
> > We assume that both timestamps are driven off the same clock [reported
> > to userspace as I915_PARAM_CS_TIMESTAMP_FREQUENCY]. Verify that this is
> > so by reading the timestamp registers around a busywait (on an otherwise
> > idle engine so there should be no preemptions).
> >
> > v2: Icelake (not ehl, nor tgl) seems to be using a fixed 80ns interval
> > for, and only for, CTX_TIMESTAMP. As far as I can tell, this behaviour
> > is undocumented.
> >
> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
> 
> 
> I really thought the CTX_TIMESTAMP was running 8 times slower :
> 
> 
> For the 2015 - 2016 Intel CoreTM Processors, CeleronTM Processors,
> and PentiumTM Processors based on the "Skylake" Platform
> 
> Volume 2c: Command Reference: Registers
> Part 1 – Registers A through L
> 
> May 2016, Revision 1.0
> 
> CTX_TIMESTAMP - Context Timestamp Count:
> 
> The granularity of this toggle is at the rate of the bit 3 in the 
> "Reported Timestamp Count"
> register(0x2358).. The toggle will be 8 times slower that "Reported 
> Timestamp Count". The
> granularity of the time stamp base unit for "Reported Timestamp Count" 
> is defined in the
> “Timestamp Bases” subsection in Power Management chapter.

I read that paragraph in the same way, that the CTX_TIMESTAMP is only
being advanced [by 1 tick] on every 8th tick of CS_TIMESTAMP.

That turns out to be not what happens... So I guess they mean that
CTX_TIMESTAMP increments by 8 every 8th tick. I haven't bothered to
check to see if there's anything in the low 2 bits of CTX_TIMESTAMP.

Still nothing mentions that Icelake has a completely different
behaviour afaict.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx