[Intel-gfx] [PATCH i-g-t 5/7] lib/debugfs: Read the crc frame counter as hex

[Ville Syrjälä]

On Tue, Dec 15, 2015 at 12:03:11PM +0000, Morton, Derek J wrote:
> >
> >
> >-----Original Message-----
> >From: Intel-gfx [mailto:intel-gfx-bounces at lists.freedesktop.org] On Behalf Of ville.syrjala at linux.intel.com
> >Sent: Monday, December 14, 2015 8:16 PM
> >To: intel-gfx at lists.freedesktop.org
> >Subject: [Intel-gfx] [PATCH i-g-t 5/7] lib/debugfs: Read the crc frame counter as hex
> >
> >From: Ville Syrjälä <ville.syrjala at linux.intel.com>
> >
> >With the kernel fixed to dump out the crc frame counts in hex, we must follow suit.
> >
> >Signed-off-by: Ville Syrjälä <ville.syrjala at linux.intel.com>
> >---
> > lib/igt_debugfs.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> >diff --git a/lib/igt_debugfs.c b/lib/igt_debugfs.c index 2c3b1cfe2370..5e71f50d7326 100644
> >--- a/lib/igt_debugfs.c
> >+++ b/lib/igt_debugfs.c
> >@@ -484,7 +484,7 @@ static bool pipe_crc_init_from_string(igt_crc_t *crc, const char *line)
> > 	int n;
> > 
> > 	crc->n_words = 5;
> >-	n = sscanf(line, "%8u %8x %8x %8x %8x %8x", &crc->frame, &crc->crc[0],
> >+	n = sscanf(line, "%8x %8x %8x %8x %8x %8x", &crc->frame, &crc->crc[0],
> 
> What will happen for kernels that have not been 'fixed'? Android is always behind drm_nightly. Is there any way of knowing whether this value is in hex or decimal and read it accordingly? What tests will be affected if this is wrong?

You might know if it's hex if the number happes to have a-f in it.
Othwerwise you can't tell since we don't use a 0x prefix.

Another option is to fix the size assumptions about the string on
both kernel and igt side.

And a third option would be to have the kernel return 'count & 0xffffff'
which would fit in the 8 characters allotted. igt wouldn't need to be
changed in this case. That might actually make some sense since on
gen3/4 the hw frame counter is only 24 bits. If userspace would have
to deal with wraparound it could just assume that it occurs at 2^24.
Actually now that I think about the current tests are probably broken
if the counter wraps sooner than 2^32. But since the interface can't
even carry such large frame counter numbers the test will simply fail
in other ways until the kernel gets fixed.

> 
> //Derek 
> 
> > 		   &crc->crc[1], &crc->crc[2], &crc->crc[3], &crc->crc[4]);
> > 	return n == 6;
> > }
> >--
> >2.4.10
> >
> >_______________________________________________
> >Intel-gfx mailing list
> >Intel-gfx at lists.freedesktop.org
> >http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> >

-- 
Ville Syrjälä
Intel OTC