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

[Chris Wilson]

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 at chris-wilson.co.uk>
> > Cc: Mika Kuoppala <mika.kuoppala at 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