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

2015-12-15 Thread Morton, Derek J 
>
>
>-Original Message-
>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of 
>ville.syrj...@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ä 
>
>With the kernel fixed to dump out the crc frame counts in hex, we must follow 
>suit.
>
>Signed-off-by: Ville Syrjälä 
>---
> 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", >frame, >crc[0],
>+  n = sscanf(line, "%8x %8x %8x %8x %8x %8x", >frame, >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?

//Derek 

>  >crc[1], >crc[2], >crc[3], >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
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

2015-12-15 Thread Ville Syrjälä 
On Tue, Dec 15, 2015 at 12:03:11PM +, Morton, Derek J wrote:
> >
> >
> >-Original Message-
> >From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf 
> >Of ville.syrj...@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ä 
> >
> >With the kernel fixed to dump out the crc frame counts in hex, we must 
> >follow suit.
> >
> >Signed-off-by: Ville Syrjälä 
> >---
> > 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", >frame, >crc[0],
> >+n = sscanf(line, "%8x %8x %8x %8x %8x %8x", >frame, >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 & 0xff'
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[1], >crc[2], >crc[3], >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