[PATCH v7 10/14] v4l2: Print out the 64-bit timestamp if we have a 64-bit timesize

[Alistair Francis]

On Sun, Apr 19, 2020 at 3:21 PM Dmitry V. Levin <ldv at altlinux.org> wrote:
>
> On Fri, Apr 17, 2020 at 09:47:20AM -0700, Alistair Francis wrote:
> > Signed-off-by: Alistair Francis <alistair.francis at wdc.com>
> > ---
> >  v4l2.c | 4 ++++
> >  1 file changed, 4 insertions(+)
> >
> > diff --git a/v4l2.c b/v4l2.c
> > index a820f8c3..51460873 100644
> > --- a/v4l2.c
> > +++ b/v4l2.c
> > @@ -488,7 +488,11 @@ print_v4l2_buffer(struct tcb *const tcp, const unsigned int code,
> >               print_v4l2_buffer_flags(b.flags);
> >               if (code == VIDIOC_DQBUF) {
> >                       tprints(", timestamp=");
> > +#if ARCH_TIMESIZE == 64
> > +                     MPERS_FUNC_NAME(print_timeval64_data_size)(&b.timestamp, sizeof(b.timestamp));
> > +#else
> >                       MPERS_FUNC_NAME(print_struct_timeval)(&b.timestamp);
> > +#endif
> >               }
> >               tprints(", ...");
> >       }
>
> After Linux commit v5.6-rc1~93^2~102 kernel supports up to 4 editions of
> struct v4l2_buffer simultaneously while out decoder can handle only up to
> 2 of them.  Unfortunately, this means that our struct v4l2_buffer decoder
> is lagging beyond the kernel, and this patch is far from filling the gap.

I'm not clear what you mean here.

In my testing I'm using the 5.4 kernel but for RV32 we expect a 64-bit
time_t here, while print_struct_timeval will only print a 32-bit
time_t.

Alistair

>
>
> --
> ldv