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

From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: "Morton, Derek J" <derek.j.morton@intel.com>
Cc: "intel-gfx@lists.freedesktop.org" <intel-gfx@lists.freedesktop.org>
Subject: Re: [PATCH i-g-t 5/7] lib/debugfs: Read the crc frame counter as hex
Date: Tue, 15 Dec 2015 14:46:02 +0200	[thread overview]
Message-ID: <20151215124602.GE4437@intel.com> (raw)
In-Reply-To: <2D016F5BA44C744783BA96B1D3EBC5BD13ED7AC8@IRSMSX102.ger.corp.intel.com>

On Tue, Dec 15, 2015 at 12:03:11PM +0000, Morton, Derek J wrote:
> >
> >
> >-----Original Message-----
> >From: Intel-gfx [mailto:intel-gfx-bounces@lists.freedesktop.org] On Behalf Of ville.syrjala@linux.intel.com
> >Sent: Monday, December 14, 2015 8:16 PM
> >To: intel-gfx@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@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@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@lists.freedesktop.org
> >http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> >

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx