[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7376001.70fALvhWdv@wuerfel>
Date: Sun, 17 Apr 2016 01:39:33 +0200
From: Arnd Bergmann <arnd@...db.de>
To: y2038@...ts.linaro.org
Cc: Tina Ruchandani <ruchandani.tina@...il.com>,
linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
David Airlie <airlied@...ux.ie>,
Benjamin Gaignard <benjamin.gaignard@...aro.org>,
Vincent Abriou <vincent.abriou@...com>
Subject: Re: [Y2038] [PATCH] drm/sti: Use 64-bit timestamps
On Wednesday 13 April 2016 02:28:02 Tina Ruchandani wrote:
> 'struct timespec' uses a 32-bit field for seconds, which
> will overflow in year 2038 and beyond. This patch is part
> of a larger attempt to remove instances of timeval, timespec
> and time_t, all of which suffer from the y2038 issue, from the
> kernel.
>
> Signed-off-by: Tina Ruchandani <ruchandani.tina@...il.com>
Looks good in principle. Two small points:
> void sti_plane_update_fps(struct sti_plane *plane,
> bool new_frame,
> bool new_field)
> {
> - struct timespec now;
> + ktime_t now;
> struct sti_fps_info *fps;
> int fpks, fipks, ms_since_last, num_frames, num_fields;
>
> - getrawmonotonic(&now);
> + now = ktime_get();
It's unclear why the driver was using getrawmonotonic() here rather
than ktime_get_ts(). The code is fairly new, so Vincent can
probably explain this.
If it was intentional, we should use ktime_get_raw() instead of
ktime_get().
> @@ -76,7 +66,7 @@ void sti_plane_update_fps(struct sti_plane *plane,
> return;
>
> fps->curr_frame_counter++;
> - ms_since_last = sti_plane_timespec_ms_diff(now, fps->last_timestamp);
> + ms_since_last = ktime_to_ms(ktime_sub(now, fps->last_timestamp));
> num_frames = fps->curr_frame_counter - fps->last_frame_counter;
This could be expressed in a more compact way using ktime_ms_delta().
Arnd
Powered by blists - more mailing lists