On Tue, Dec 15, 2015 at 12:03:11PM +0000, Morton, Derek J wrote: > > > > > >-----Original Message----- > >From: Intel-gfx [mailto:[email protected]] On Behalf > >Of [email protected] > >Sent: Monday, December 14, 2015 8:16 PM > >To: [email protected] > >Subject: [Intel-gfx] [PATCH i-g-t 5/7] lib/debugfs: Read the crc frame > >counter as hex > > > >From: Ville Syrjälä <[email protected]> > > > >With the kernel fixed to dump out the crc frame counts in hex, we must > >follow suit. > > > >Signed-off-by: Ville Syrjälä <[email protected]> > >--- > > 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 > >[email protected] > >http://lists.freedesktop.org/mailman/listinfo/intel-gfx > > -- Ville Syrjälä Intel OTC _______________________________________________ Intel-gfx mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/intel-gfx
