[6/7,RFC,media] : v4l2: introduce v4l2_timeval
Commit Message
The v4l2 API uses a 'struct timeval' to communicate time stamps to user
space. This is broken on 32-bit architectures as soon as we have a C library
that defines time_t as 64 bit, which then changes the structure layout of
struct v4l2_buffer.
Fortunately, almost all v4l2 drivers use monotonic timestamps and call
v4l2_get_timestamp(), which means they don't also have a y2038 problem.
This means we can keep using the existing binary layout of the structure
and do not need to worry about defining a new kernel interface for
userland with 64-bit time_t.
A possible downside of this approach is that it breaks any user space
that tries to assign the timeval structure returned from the kernel
to another timeval, or to pass a pointer to it into a function that
expects a timeval. Those will cause a build-time warning or error
that can be fixed up in a backwards compatible way.
The alternative to this patch is to leave the structure using
'struct timeval', but then we have to rework the kernel to let
it handle both 32-bit and 64-bit time_t for 32-bit user space
processes.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/media/pci/bt8xx/bttv-driver.c | 2 +-
drivers/media/pci/meye/meye.h | 2 +-
drivers/media/pci/zoran/zoran.h | 2 +-
drivers/media/platform/coda/coda.h | 2 +-
drivers/media/platform/omap/omap_vout.c | 4 ++--
drivers/media/platform/omap3isp/ispstat.h | 2 +-
drivers/media/platform/vim2m.c | 2 +-
drivers/media/platform/vivid/vivid-ctrls.c | 2 +-
drivers/media/usb/cpia2/cpia2.h | 2 +-
drivers/media/usb/cpia2/cpia2_v4l.c | 2 +-
drivers/media/usb/gspca/gspca.c | 2 +-
drivers/media/usb/usbvision/usbvision.h | 2 +-
drivers/media/v4l2-core/v4l2-common.c | 6 +++---
include/media/v4l2-common.h | 2 +-
include/media/videobuf-core.h | 2 +-
include/trace/events/v4l2.h | 12 ++++++++++--
include/uapi/linux/omap3isp.h | 2 +-
include/uapi/linux/videodev2.h | 8 +++++++-
18 files changed, 36 insertions(+), 22 deletions(-)
Comments
On 09/15/2015 05:49 PM, Arnd Bergmann wrote:
> The v4l2 API uses a 'struct timeval' to communicate time stamps to user
> space. This is broken on 32-bit architectures as soon as we have a C library
> that defines time_t as 64 bit, which then changes the structure layout of
> struct v4l2_buffer.
>
> Fortunately, almost all v4l2 drivers use monotonic timestamps and call
> v4l2_get_timestamp(), which means they don't also have a y2038 problem.
> This means we can keep using the existing binary layout of the structure
> and do not need to worry about defining a new kernel interface for
> userland with 64-bit time_t.
>
> A possible downside of this approach is that it breaks any user space
> that tries to assign the timeval structure returned from the kernel
> to another timeval, or to pass a pointer to it into a function that
> expects a timeval. Those will cause a build-time warning or error
> that can be fixed up in a backwards compatible way.
>
> The alternative to this patch is to leave the structure using
> 'struct timeval', but then we have to rework the kernel to let
> it handle both 32-bit and 64-bit time_t for 32-bit user space
> processes.
Cool. Only this morning I was thinking about what would be needed in v4l2
to be y2038 safe, and here it is!
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index 3228fbebcd63..b02cf054fbb8 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -803,6 +803,12 @@ struct v4l2_plane {
> __u32 reserved[11];
> };
>
> +/* used for monotonic times, therefore y2038 safe */
> +struct v4l2_timeval {
> + long tv_sec;
> + long tv_usec;
> +};
> +
> /**
> * struct v4l2_buffer - video buffer info
> * @index: id number of the buffer
> @@ -839,7 +845,7 @@ struct v4l2_buffer {
> __u32 bytesused;
> __u32 flags;
> __u32 field;
> - struct timeval timestamp;
> + struct v4l2_timeval timestamp;
> struct v4l2_timecode timecode;
> __u32 sequence;
>
>
I suspect that quite a few apps use assign the timestamp to another timeval
struct. A quick grep in v4l-utils (which we maintain) shows at least two of
those assignments. Ditto for xawtv3.
So I don't think v4l2_timeval is an option as it would break userspace too badly.
An alternative to supporting a 64-bit timeval for 32-bit userspace is to make a
new y2038-aware struct and a new set of ioctls and use this opportunity to clean
up and extend the v4l2_buffer struct.
So any 32-bit app that needs to be y2038 compliant would just use the new
struct and ioctls.
But this is something to discuss among the v4l2 developers.
Regards,
Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tuesday 15 September 2015 18:27:19 Hans Verkuil wrote:
> On 09/15/2015 05:49 PM, Arnd Bergmann wrote:
> > The v4l2 API uses a 'struct timeval' to communicate time stamps to user
> > space. This is broken on 32-bit architectures as soon as we have a C library
> > that defines time_t as 64 bit, which then changes the structure layout of
> > struct v4l2_buffer.
> >
> > Fortunately, almost all v4l2 drivers use monotonic timestamps and call
> > v4l2_get_timestamp(), which means they don't also have a y2038 problem.
> > This means we can keep using the existing binary layout of the structure
> > and do not need to worry about defining a new kernel interface for
> > userland with 64-bit time_t.
> >
> > A possible downside of this approach is that it breaks any user space
> > that tries to assign the timeval structure returned from the kernel
> > to another timeval, or to pass a pointer to it into a function that
> > expects a timeval. Those will cause a build-time warning or error
> > that can be fixed up in a backwards compatible way.
> >
> > The alternative to this patch is to leave the structure using
> > 'struct timeval', but then we have to rework the kernel to let
> > it handle both 32-bit and 64-bit time_t for 32-bit user space
> > processes.
>
> Cool. Only this morning I was thinking about what would be needed in v4l2
> to be y2038 safe, and here it is!
Nice!
fwiw, I also have a list of drivers at
https://docs.google.com/spreadsheets/d/1HCYwHXxs48TsTb6IGUduNjQnmfRvMPzCN6T_0YiQwis/edit?usp=sharing
which lists all known files that still need changing, in case you are
wondering what else needs to be done, though it currently only covers
things that nobody so far has started working on, and I have a couple
patches on my disk that need polishing (I pushed out the v4l2 portion
of that as a start)
> > @@ -839,7 +845,7 @@ struct v4l2_buffer {
> > __u32 bytesused;
> > __u32 flags;
> > __u32 field;
> > - struct timeval timestamp;
> > + struct v4l2_timeval timestamp;
> > struct v4l2_timecode timecode;
> > __u32 sequence;
> >
> >
>
> I suspect that quite a few apps use assign the timestamp to another timeval
> struct. A quick grep in v4l-utils (which we maintain) shows at least two of
> those assignments. Ditto for xawtv3.
Ok, that is very helpful information, thanks for finding that!
> So I don't think v4l2_timeval is an option as it would break userspace too badly.
Agreed, we definitely don't want to break building user space with
existing environments, i.e. 64-bit architectures, or 32-bit architectures
with 32-bit time_t.
> An alternative to supporting a 64-bit timeval for 32-bit userspace is to make a
> new y2038-aware struct and a new set of ioctls and use this opportunity to clean
> up and extend the v4l2_buffer struct.
>
> So any 32-bit app that needs to be y2038 compliant would just use the new
> struct and ioctls.
>
> But this is something to discuss among the v4l2 developers.
Ok. We generally to require as few source level changes to user space
as possible for the conversion, and we want to make sure that when
using a 32-bit libc with 64-bit time_t, we don't accidentally get
broken interfaces (i.e. we should get a compile error whenever we
can't get it right automatically).
One aspect that makes v4l2_buffer special is that the binary format
is already clean for y2038 (once patch 4/7 "exynos4-is: use monotonic
timestamps as advertized" gets merged), and we only need to worry about
what happens when user space disagrees about the size of timeval.
Let me describe the options that I can think of here:
a) Similar to my first attempt, define a new struct v4l2_timeval, but
only use it when building with a y2038-aware libc, so we don't break
existing environments:
/* some compile-time conditional that we first need to agree on with libc */
#if __BITS_PER_TIME_T > __BITS_PER_LONG
struct v4l2_timeval { long tv_sec; long tv_usec; }
#else
#define v4l2_timeval timeval
#endif
This means that any user space that currently assumes the timestamp
member to be a 'struct timeval' has to be changed to access the members
individually, or get a build error.
The __BITS_PER_TIME_T trick has to be used in a couple of other subsystems
too, as some of them have no other way to identify an interface
b) Keep the header file unchanged, but deal with both formats of v4l2_buffer
in the kernel. Fortunately, all ioctls that pass a v4l2_buffer have
properly defined command codes, and it does not get passed using a
read/write style interface. This means we move the v4l2_buffer32
handling from v4l2-compat-ioctl32.c to v4l2-ioctl.c and add an in-kernel
v4l2_buffer64 that matches the 64-bit variant of v4l2_buffer.
This way, user space can use either definition of time_t, and the
kernel will just handle them natively.
This is going to be the most common way to handle y2038 compatibility
in device drivers, and it has the additional advantage of simplifying
the compat path.
c) As you describe above, introduce a new v4l2_buffer replacement with
a different layout that does not reference timeval. For this case, I
would recommend using a single 64-bit nanosecond timestamp that can
be generated using ktime_get_ns().
However, to avoid ambiguity with the user space definition of struct
timeval, we still have to hide the existing 'struct v4l2_buffer' from
y2038-aware user space by enclosing it in '#if __BITS_PER_TIME_T >
__BITS_PER_LONG' or similar.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On 09/15/2015 10:26 PM, Arnd Bergmann wrote:
> On Tuesday 15 September 2015 18:27:19 Hans Verkuil wrote:
>> On 09/15/2015 05:49 PM, Arnd Bergmann wrote:
>>> The v4l2 API uses a 'struct timeval' to communicate time stamps to user
>>> space. This is broken on 32-bit architectures as soon as we have a C library
>>> that defines time_t as 64 bit, which then changes the structure layout of
>>> struct v4l2_buffer.
>>>
>>> Fortunately, almost all v4l2 drivers use monotonic timestamps and call
>>> v4l2_get_timestamp(), which means they don't also have a y2038 problem.
>>> This means we can keep using the existing binary layout of the structure
>>> and do not need to worry about defining a new kernel interface for
>>> userland with 64-bit time_t.
>>>
>>> A possible downside of this approach is that it breaks any user space
>>> that tries to assign the timeval structure returned from the kernel
>>> to another timeval, or to pass a pointer to it into a function that
>>> expects a timeval. Those will cause a build-time warning or error
>>> that can be fixed up in a backwards compatible way.
>>>
>>> The alternative to this patch is to leave the structure using
>>> 'struct timeval', but then we have to rework the kernel to let
>>> it handle both 32-bit and 64-bit time_t for 32-bit user space
>>> processes.
>>
>> Cool. Only this morning I was thinking about what would be needed in v4l2
>> to be y2038 safe, and here it is!
>
> Nice!
>
> fwiw, I also have a list of drivers at
> https://docs.google.com/spreadsheets/d/1HCYwHXxs48TsTb6IGUduNjQnmfRvMPzCN6T_0YiQwis/edit?usp=sharing
> which lists all known files that still need changing, in case you are
> wondering what else needs to be done, though it currently only covers
> things that nobody so far has started working on, and I have a couple
> patches on my disk that need polishing (I pushed out the v4l2 portion
> of that as a start)
I just *thought* about it, I never said I would do it! :-)
>
>>> @@ -839,7 +845,7 @@ struct v4l2_buffer {
>>> __u32 bytesused;
>>> __u32 flags;
>>> __u32 field;
>>> - struct timeval timestamp;
>>> + struct v4l2_timeval timestamp;
>>> struct v4l2_timecode timecode;
>>> __u32 sequence;
>>>
>>>
>>
>> I suspect that quite a few apps use assign the timestamp to another timeval
>> struct. A quick grep in v4l-utils (which we maintain) shows at least two of
>> those assignments. Ditto for xawtv3.
>
> Ok, that is very helpful information, thanks for finding that!
>
>> So I don't think v4l2_timeval is an option as it would break userspace too badly.
>
> Agreed, we definitely don't want to break building user space with
> existing environments, i.e. 64-bit architectures, or 32-bit architectures
> with 32-bit time_t.
>
>> An alternative to supporting a 64-bit timeval for 32-bit userspace is to make a
>> new y2038-aware struct and a new set of ioctls and use this opportunity to clean
>> up and extend the v4l2_buffer struct.
>>
>> So any 32-bit app that needs to be y2038 compliant would just use the new
>> struct and ioctls.
>>
>> But this is something to discuss among the v4l2 developers.
>
> Ok. We generally to require as few source level changes to user space
> as possible for the conversion, and we want to make sure that when
> using a 32-bit libc with 64-bit time_t, we don't accidentally get
> broken interfaces (i.e. we should get a compile error whenever we
> can't get it right automatically).
>
> One aspect that makes v4l2_buffer special is that the binary format
> is already clean for y2038 (once patch 4/7 "exynos4-is: use monotonic
> timestamps as advertized" gets merged), and we only need to worry about
> what happens when user space disagrees about the size of timeval.
>
> Let me describe the options that I can think of here:
>
> a) Similar to my first attempt, define a new struct v4l2_timeval, but
> only use it when building with a y2038-aware libc, so we don't break
> existing environments:
>
> /* some compile-time conditional that we first need to agree on with libc */
> #if __BITS_PER_TIME_T > __BITS_PER_LONG
> struct v4l2_timeval { long tv_sec; long tv_usec; }
> #else
> #define v4l2_timeval timeval
> #endif
>
> This means that any user space that currently assumes the timestamp
> member to be a 'struct timeval' has to be changed to access the members
> individually, or get a build error.
> The __BITS_PER_TIME_T trick has to be used in a couple of other subsystems
> too, as some of them have no other way to identify an interface
I don't like this as this means some applications will compile on 64 bit or
with a non-y2038-aware libc, but fail on a 32-bit with y2038-aware libc. This
will be confusing and it may take a long time before the application developer
discovers this.
> b) Keep the header file unchanged, but deal with both formats of v4l2_buffer
> in the kernel. Fortunately, all ioctls that pass a v4l2_buffer have
> properly defined command codes, and it does not get passed using a
> read/write style interface. This means we move the v4l2_buffer32
> handling from v4l2-compat-ioctl32.c to v4l2-ioctl.c and add an in-kernel
> v4l2_buffer64 that matches the 64-bit variant of v4l2_buffer.
> This way, user space can use either definition of time_t, and the
> kernel will just handle them natively.
> This is going to be the most common way to handle y2038 compatibility
> in device drivers, and it has the additional advantage of simplifying
> the compat path.
This would work.
> c) As you describe above, introduce a new v4l2_buffer replacement with
> a different layout that does not reference timeval. For this case, I
> would recommend using a single 64-bit nanosecond timestamp that can
> be generated using ktime_get_ns().
> However, to avoid ambiguity with the user space definition of struct
> timeval, we still have to hide the existing 'struct v4l2_buffer' from
> y2038-aware user space by enclosing it in '#if __BITS_PER_TIME_T >
> __BITS_PER_LONG' or similar.
Right, and if we do that we still have the problem I describe under a). So we
would need to implement b) regardless.
In other words, choosing c) doesn't depend on y2038 and it should be decided
on its own merits.
I've proposed this as a topic to the media workshop we'll have during the Linux
Kernel Summit.
Regards,
Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wednesday 16 September 2015 08:51:14 Hans Verkuil wrote:
> > a) Similar to my first attempt, define a new struct v4l2_timeval, but
> > only use it when building with a y2038-aware libc, so we don't break
> > existing environments:
> >
> > /* some compile-time conditional that we first need to agree on with libc */
> > #if __BITS_PER_TIME_T > __BITS_PER_LONG
> > struct v4l2_timeval { long tv_sec; long tv_usec; }
> > #else
> > #define v4l2_timeval timeval
> > #endif
> >
> > This means that any user space that currently assumes the timestamp
> > member to be a 'struct timeval' has to be changed to access the members
> > individually, or get a build error.
> > The __BITS_PER_TIME_T trick has to be used in a couple of other subsystems
> > too, as some of them have no other way to identify an interface
>
> I don't like this as this means some applications will compile on 64 bit or
> with a non-y2038-aware libc, but fail on a 32-bit with y2038-aware libc. This
> will be confusing and it may take a long time before the application developer
> discovers this.
Right.
> > b) Keep the header file unchanged, but deal with both formats of v4l2_buffer
> > in the kernel. Fortunately, all ioctls that pass a v4l2_buffer have
> > properly defined command codes, and it does not get passed using a
> > read/write style interface. This means we move the v4l2_buffer32
> > handling from v4l2-compat-ioctl32.c to v4l2-ioctl.c and add an in-kernel
> > v4l2_buffer64 that matches the 64-bit variant of v4l2_buffer.
> > This way, user space can use either definition of time_t, and the
> > kernel will just handle them natively.
> > This is going to be the most common way to handle y2038 compatibility
> > in device drivers, and it has the additional advantage of simplifying
> > the compat path.
>
> This would work.
Ok. So the only downside I can think of for this is that it uses a slightly
less efficient format with additional padding in it. The kernel side will
be a little ugly as I'm trying to avoid defining a generic timeval64
structure (the generic syscalls should not need one), but I'll try to
implement it first to see how it ends up.
> > c) As you describe above, introduce a new v4l2_buffer replacement with
> > a different layout that does not reference timeval. For this case, I
> > would recommend using a single 64-bit nanosecond timestamp that can
> > be generated using ktime_get_ns().
> > However, to avoid ambiguity with the user space definition of struct
> > timeval, we still have to hide the existing 'struct v4l2_buffer' from
> > y2038-aware user space by enclosing it in '#if __BITS_PER_TIME_T >
> > __BITS_PER_LONG' or similar.
>
> Right, and if we do that we still have the problem I describe under a). So we
> would need to implement b) regardless.
>
> In other words, choosing c) doesn't depend on y2038 and it should be decided
> on its own merits.
>
> I've proposed this as a topic to the media workshop we'll have during the Linux
> Kernel Summit.
Thanks, good idea. I'll be at the kernel summit, but don't plan to attend
the media workshop otherwise. If you let me know about the schedule, I can
come to this session (or ping me on IRC or hangout when it starts).
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On 09/16/2015 09:56 AM, Arnd Bergmann wrote:
> On Wednesday 16 September 2015 08:51:14 Hans Verkuil wrote:
>
>>> a) Similar to my first attempt, define a new struct v4l2_timeval, but
>>> only use it when building with a y2038-aware libc, so we don't break
>>> existing environments:
>>>
>>> /* some compile-time conditional that we first need to agree on with libc */
>>> #if __BITS_PER_TIME_T > __BITS_PER_LONG
>>> struct v4l2_timeval { long tv_sec; long tv_usec; }
>>> #else
>>> #define v4l2_timeval timeval
>>> #endif
>>>
>>> This means that any user space that currently assumes the timestamp
>>> member to be a 'struct timeval' has to be changed to access the members
>>> individually, or get a build error.
>>> The __BITS_PER_TIME_T trick has to be used in a couple of other subsystems
>>> too, as some of them have no other way to identify an interface
>>
>> I don't like this as this means some applications will compile on 64 bit or
>> with a non-y2038-aware libc, but fail on a 32-bit with y2038-aware libc. This
>> will be confusing and it may take a long time before the application developer
>> discovers this.
>
> Right.
>
>>> b) Keep the header file unchanged, but deal with both formats of v4l2_buffer
>>> in the kernel. Fortunately, all ioctls that pass a v4l2_buffer have
>>> properly defined command codes, and it does not get passed using a
>>> read/write style interface. This means we move the v4l2_buffer32
>>> handling from v4l2-compat-ioctl32.c to v4l2-ioctl.c and add an in-kernel
>>> v4l2_buffer64 that matches the 64-bit variant of v4l2_buffer.
>>> This way, user space can use either definition of time_t, and the
>>> kernel will just handle them natively.
>>> This is going to be the most common way to handle y2038 compatibility
>>> in device drivers, and it has the additional advantage of simplifying
>>> the compat path.
>>
>> This would work.
>
> Ok. So the only downside I can think of for this is that it uses a slightly
> less efficient format with additional padding in it. The kernel side will
> be a little ugly as I'm trying to avoid defining a generic timeval64
> structure (the generic syscalls should not need one), but I'll try to
> implement it first to see how it ends up.
>
>>> c) As you describe above, introduce a new v4l2_buffer replacement with
>>> a different layout that does not reference timeval. For this case, I
>>> would recommend using a single 64-bit nanosecond timestamp that can
>>> be generated using ktime_get_ns().
>>> However, to avoid ambiguity with the user space definition of struct
>>> timeval, we still have to hide the existing 'struct v4l2_buffer' from
>>> y2038-aware user space by enclosing it in '#if __BITS_PER_TIME_T >
>>> __BITS_PER_LONG' or similar.
>>
>> Right, and if we do that we still have the problem I describe under a). So we
>> would need to implement b) regardless.
>>
>> In other words, choosing c) doesn't depend on y2038 and it should be decided
>> on its own merits.
>>
>> I've proposed this as a topic to the media workshop we'll have during the Linux
>> Kernel Summit.
>
> Thanks, good idea. I'll be at the kernel summit, but don't plan to attend
> the media workshop otherwise. If you let me know about the schedule, I can
> come to this session (or ping me on IRC or hangout when it starts).
Are you also attending the ELCE in Dublin? We could have a quick talk there.
I think the discussion whether to switch to a new v4l2_buffer struct isn't really
dependent on anything y2038.
Regards,
Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wednesday 16 September 2015 10:12:00 Hans Verkuil wrote:
>
> Are you also attending the ELCE in Dublin? We could have a quick talk there.
> I think the discussion whether to switch to a new v4l2_buffer struct isn't really
> dependent on anything y2038.
No, unfortunately I won't be there.
Concerning a v4l2_buffer, I agree we should treat that as a completely independent
topic. The problem at hand for y2038 is only about we expect to happen when someone
compiles source code that uses the existing v4l2_buffer (and v4l2_event) with a
y2038-aware libc.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
@@ -3585,7 +3585,7 @@ static void
bttv_irq_wakeup_video(struct bttv *btv, struct bttv_buffer_set *wakeup,
struct bttv_buffer_set *curr, unsigned int state)
{
- struct timeval ts;
+ struct v4l2_timeval ts;
v4l2_get_timestamp(&ts);
@@ -281,7 +281,7 @@
struct meye_grab_buffer {
int state; /* state of buffer */
unsigned long size; /* size of jpg frame */
- struct timeval timestamp; /* timestamp */
+ struct v4l2_timeval timestamp; /* timestamp */
unsigned long sequence; /* sequence number */
};
@@ -39,7 +39,7 @@ struct zoran_sync {
unsigned long frame; /* number of buffer that has been free'd */
unsigned long length; /* number of code bytes in buffer (capture only) */
unsigned long seq; /* frame sequence number */
- struct timeval timestamp; /* timestamp */
+ struct v4l2_timeval timestamp; /* timestamp */
};
@@ -138,7 +138,7 @@ struct coda_buffer_meta {
struct list_head list;
u32 sequence;
struct v4l2_timecode timecode;
- struct timeval timestamp;
+ struct v4l2_timeval timestamp;
u32 start;
u32 end;
};
@@ -513,7 +513,7 @@ static int omapvid_apply_changes(struct omap_vout_device *vout)
}
static int omapvid_handle_interlace_display(struct omap_vout_device *vout,
- unsigned int irqstatus, struct timeval timevalue)
+ unsigned int irqstatus, struct v4l2_timeval timevalue)
{
u32 fid;
@@ -557,7 +557,7 @@ static void omap_vout_isr(void *arg, unsigned int irqstatus)
int ret, fid, mgr_id;
u32 addr, irq;
struct omap_overlay *ovl;
- struct timeval timevalue;
+ struct v4l2_timeval timevalue;
struct omapvideo_info *ovid;
struct omap_dss_device *cur_display;
struct omap_vout_device *vout = (struct omap_vout_device *)arg;
@@ -39,7 +39,7 @@ struct ispstat_buffer {
struct sg_table sgt;
void *virt_addr;
dma_addr_t dma_addr;
- struct timeval ts;
+ struct v4l2_timeval ts;
u32 buf_size;
u32 frame_number;
u16 config_counter;
@@ -235,7 +235,7 @@ static int device_process(struct vim2m_ctx *ctx,
in_vb->v4l2_buf.sequence = q_data->sequence++;
memcpy(&out_vb->v4l2_buf.timestamp,
&in_vb->v4l2_buf.timestamp,
- sizeof(struct timeval));
+ sizeof(struct v4l2_timeval));
if (in_vb->v4l2_buf.flags & V4L2_BUF_FLAG_TIMECODE)
memcpy(&out_vb->v4l2_buf.timecode, &in_vb->v4l2_buf.timecode,
sizeof(struct v4l2_timecode));
@@ -935,7 +935,7 @@ static const struct v4l2_ctrl_config vivid_ctrl_has_scaler_out = {
static int vivid_streaming_s_ctrl(struct v4l2_ctrl *ctrl)
{
struct vivid_dev *dev = container_of(ctrl->handler, struct vivid_dev, ctrl_hdl_streaming);
- struct timeval tv;
+ struct v4l2_timeval tv;
switch (ctrl->id) {
case VIVID_CID_DQBUF_ERROR:
@@ -354,7 +354,7 @@ struct cpia2_sbuf {
};
struct framebuf {
- struct timeval timestamp;
+ struct v4l2_timeval timestamp;
unsigned long seq;
int num;
int length;
@@ -892,7 +892,7 @@ static int find_earliest_filled_buffer(struct camera_data *cam)
found = i;
} else {
/* find which buffer is earlier */
- struct timeval *tv1, *tv2;
+ struct v4l2_timeval *tv1, *tv2;
tv1 = &cam->buffers[i].timestamp;
tv2 = &cam->buffers[found].timestamp;
if(tv1->tv_sec < tv2->tv_sec ||
@@ -1898,7 +1898,7 @@ static ssize_t dev_read(struct file *file, char __user *data,
struct gspca_dev *gspca_dev = video_drvdata(file);
struct gspca_frame *frame;
struct v4l2_buffer v4l2_buf;
- struct timeval timestamp;
+ struct v4l2_timeval timestamp;
int n, ret, ret2;
PDEBUG(D_FRAM, "read (%zd)", count);
@@ -320,7 +320,7 @@ struct usbvision_frame {
long bytes_read; /* amount of scanlength that has been read from data */
struct usbvision_v4l2_format_st v4l2_format; /* format the user needs*/
int v4l2_linesize; /* bytes for one videoline*/
- struct timeval timestamp;
+ struct v4l2_timeval timestamp;
int sequence; /* How many video frames we send to user */
};
@@ -396,11 +396,11 @@ const struct v4l2_frmsize_discrete *v4l2_find_nearest_format(
}
EXPORT_SYMBOL_GPL(v4l2_find_nearest_format);
-void v4l2_get_timestamp(struct timeval *tv)
+void v4l2_get_timestamp(struct v4l2_timeval *tv)
{
- struct timespec ts;
+ struct timespec64 ts;
- ktime_get_ts(&ts);
+ ktime_get_ts64(&ts);
tv->tv_sec = ts.tv_sec;
tv->tv_usec = ts.tv_nsec / NSEC_PER_USEC;
}
@@ -187,6 +187,6 @@ const struct v4l2_frmsize_discrete *v4l2_find_nearest_format(
const struct v4l2_discrete_probe *probe,
s32 width, s32 height);
-void v4l2_get_timestamp(struct timeval *tv);
+void v4l2_get_timestamp(struct v4l2_timeval *tv);
#endif /* V4L2_COMMON_H_ */
@@ -80,7 +80,7 @@ struct videobuf_buffer {
struct list_head queue;
wait_queue_head_t done;
unsigned int field_count;
- struct timeval ts;
+ struct v4l2_timeval ts;
/* Memory type */
enum v4l2_memory memory;
@@ -6,6 +6,14 @@
#include <linux/tracepoint.h>
+#ifndef v4l2_timeval_to_ns
+#define v4l2_timeval_to_ns v4l2_timeval_to_ns
+static inline u64 v4l2_timeval_to_ns(struct v4l2_timeval *tv)
+{
+ return (u64)tv->tv_sec * NSEC_PER_SEC + tv->tv_usec * NSEC_PER_USEC;
+}
+#endif
+
/* Enums require being exported to userspace, for user tool parsing */
#undef EM
#undef EMe
@@ -126,7 +134,7 @@ DECLARE_EVENT_CLASS(v4l2_event_class,
__entry->bytesused = buf->bytesused;
__entry->flags = buf->flags;
__entry->field = buf->field;
- __entry->timestamp = timeval_to_ns(&buf->timestamp);
+ __entry->timestamp = v4l2_timeval_to_ns(&buf->timestamp);
__entry->timecode_type = buf->timecode.type;
__entry->timecode_flags = buf->timecode.flags;
__entry->timecode_frames = buf->timecode.frames;
@@ -211,7 +219,7 @@ DECLARE_EVENT_CLASS(vb2_event_class,
__entry->bytesused = vb->v4l2_planes[0].bytesused;
__entry->flags = vb->v4l2_buf.flags;
__entry->field = vb->v4l2_buf.field;
- __entry->timestamp = timeval_to_ns(&vb->v4l2_buf.timestamp);
+ __entry->timestamp = v4l2_timeval_to_ns(&vb->v4l2_buf.timestamp);
__entry->timecode_type = vb->v4l2_buf.timecode.type;
__entry->timecode_flags = vb->v4l2_buf.timecode.flags;
__entry->timecode_frames = vb->v4l2_buf.timecode.frames;
@@ -164,7 +164,7 @@ struct omap3isp_h3a_aewb_config {
* @config_counter: Number of the configuration associated with the data.
*/
struct omap3isp_stat_data {
- struct timeval ts;
+ struct v4l2_timeval ts;
void __user *buf;
__u32 buf_size;
__u16 frame_number;
@@ -803,6 +803,12 @@ struct v4l2_plane {
__u32 reserved[11];
};
+/* used for monotonic times, therefore y2038 safe */
+struct v4l2_timeval {
+ long tv_sec;
+ long tv_usec;
+};
+
/**
* struct v4l2_buffer - video buffer info
* @index: id number of the buffer
@@ -839,7 +845,7 @@ struct v4l2_buffer {
__u32 bytesused;
__u32 flags;
__u32 field;
- struct timeval timestamp;
+ struct v4l2_timeval timestamp;
struct v4l2_timecode timecode;
__u32 sequence;