License cleanup: add SPDX GPL-2.0 license identifier to files with no license
Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.
By default all files without license information are under the default
license of the kernel, which is GPL version 2.
Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.
This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.
How this work was done:
Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,
Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.
The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.
The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.
Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if <5
lines).
All documentation files were explicitly excluded.
The following heuristics were used to determine which SPDX license
identifiers to apply.
- when both scanners couldn't find any license traces, file was
considered to have no license information in it, and the top level
COPYING file license applied.
For non */uapi/* files that summary was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 11139
and resulted in the first patch in this series.
If that file was a */uapi/* path one, it was "GPL-2.0 WITH
Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 WITH Linux-syscall-note 930
and resulted in the second patch in this series.
- if a file had some form of licensing information in it, and was one
of the */uapi/* ones, it was denoted with the Linux-syscall-note if
any GPL family license was found in the file or had no licensing in
it (per prior point). Results summary:
SPDX license identifier # files
---------------------------------------------------|------
GPL-2.0 WITH Linux-syscall-note 270
GPL-2.0+ WITH Linux-syscall-note 169
((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21
((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17
LGPL-2.1+ WITH Linux-syscall-note 15
GPL-1.0+ WITH Linux-syscall-note 14
((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5
LGPL-2.0+ WITH Linux-syscall-note 4
LGPL-2.1 WITH Linux-syscall-note 3
((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3
((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1
and that resulted in the third patch in this series.
- when the two scanners agreed on the detected license(s), that became
the concluded license(s).
- when there was disagreement between the two scanners (one detected a
license but the other didn't, or they both detected different
licenses) a manual inspection of the file occurred.
- In most cases a manual inspection of the information in the file
resulted in a clear resolution of the license that should apply (and
which scanner probably needed to revisit its heuristics).
- When it was not immediately clear, the license identifier was
confirmed with lawyers working with the Linux Foundation.
- If there was any question as to the appropriate license identifier,
the file was flagged for further research and to be revisited later
in time.
In total, over 70 hours of logged manual review was done on the
spreadsheet to determine the SPDX license identifiers to apply to the
source files by Kate, Philippe, Thomas and, in some cases, confirmation
by lawyers working with the Linux Foundation.
Kate also obtained a third independent scan of the 4.13 code base from
FOSSology, and compared selected files where the other two scanners
disagreed against that SPDX file, to see if there was new insights. The
Windriver scanner is based on an older version of FOSSology in part, so
they are related.
Thomas did random spot checks in about 500 files from the spreadsheets
for the uapi headers and agreed with SPDX license identifier in the
files he inspected. For the non-uapi files Thomas did random spot checks
in about 15000 files.
In initial set of patches against 4.14-rc6, 3 files were found to have
copy/paste license identifier errors, and have been fixed to reflect the
correct identifier.
Additionally Philippe spent 10 hours this week doing a detailed manual
inspection and review of the 12,461 patched files from the initial patch
version early this week with:
- a full scancode scan run, collecting the matched texts, detected
license ids and scores
- reviewing anything where there was a license detected (about 500+
files) to ensure that the applied SPDX license was correct
- reviewing anything where there was no detection but the patch license
was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
SPDX license was correct
This produced a worksheet with 20 files needing minor correction. This
worksheet was then exported into 3 different .csv files for the
different types of files to be modified.
These .csv files were then reviewed by Greg. Thomas wrote a script to
parse the csv files and add the proper SPDX tag to the file, in the
format that the file expected. This script was further refined by Greg
based on the output to detect more types of files automatically and to
distinguish between header and source .c files (which need different
comment types.) Finally Greg ran the script using the .csv files to
generate the patches.
Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-11-01 22:07:57 +08:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0 */
|
2014-07-17 05:04:02 +08:00
|
|
|
#ifndef _LINUX_TIMEKEEPING_H
|
|
|
|
|
#define _LINUX_TIMEKEEPING_H
|
|
|
|
|
|
2016-09-22 22:48:17 +08:00
|
|
|
#include <linux/errno.h>
|
2016-04-08 14:02:12 +08:00
|
|
|
|
2014-07-17 05:04:02 +08:00
|
|
|
/* Included from linux/ktime.h */
|
|
|
|
|
|
|
|
|
|
void timekeeping_init(void);
|
|
|
|
|
extern int timekeeping_suspended;
|
|
|
|
|
|
2017-02-05 21:53:36 +08:00
|
|
|
/* Architecture timer tick functions: */
|
|
|
|
|
extern void update_process_times(int user);
|
|
|
|
|
extern void xtime_update(unsigned long ticks);
|
|
|
|
|
|
2014-07-17 05:04:02 +08:00
|
|
|
/*
|
|
|
|
|
* Get and set timeofday
|
|
|
|
|
*/
|
2014-11-18 19:15:16 +08:00
|
|
|
extern int do_settimeofday64(const struct timespec64 *ts);
|
2016-04-08 14:02:12 +08:00
|
|
|
extern int do_sys_settimeofday64(const struct timespec64 *tv,
|
|
|
|
|
const struct timezone *tz);
|
2014-07-17 05:04:02 +08:00
|
|
|
/*
|
|
|
|
|
* Kernel time accessors
|
|
|
|
|
*/
|
2015-07-29 20:09:43 +08:00
|
|
|
struct timespec64 current_kernel_time64(void);
|
|
|
|
|
|
2014-07-17 05:04:02 +08:00
|
|
|
/*
|
2017-10-19 19:14:49 +08:00
|
|
|
* timespec64 based interfaces
|
2014-07-17 05:04:02 +08:00
|
|
|
*/
|
2014-11-08 03:20:40 +08:00
|
|
|
struct timespec64 get_monotonic_coarse64(void);
|
2014-11-08 03:03:20 +08:00
|
|
|
extern void getrawmonotonic64(struct timespec64 *ts);
|
2014-07-17 05:04:04 +08:00
|
|
|
extern void ktime_get_ts64(struct timespec64 *ts);
|
2014-10-29 18:31:16 +08:00
|
|
|
extern time64_t ktime_get_seconds(void);
|
kdb: use __ktime_get_real_seconds instead of __current_kernel_time
kdb is the only user of the __current_kernel_time() interface, which is
not y2038 safe and should be removed at some point.
The kdb code also goes to great lengths to print the time in a
human-readable format from 'struct timespec', again using a non-y2038-safe
re-implementation of the generic time_to_tm() code.
Using __current_kernel_time() here is necessary since the regular
accessors that require a sequence lock might hang when called during the
xtime update. However, this is safe in the particular case since kdb is
only interested in the tv_sec field that is updated atomically.
In order to make this y2038-safe, I'm converting the code to the generic
time64_to_tm helper, but that introduces the problem that we have no
interface like __current_kernel_time() that provides a 64-bit timestamp
in a lockless, safe and architecture-independent way. I have multiple
ideas for how to solve that:
- __ktime_get_real_seconds() is lockless, but can return
incorrect results on 32-bit architectures in the special case that
we are in the process of changing the time across the epoch, either
during the timer tick that overflows the seconds in 2038, or while
calling settimeofday.
- ktime_get_real_fast_ns() would work in this context, but does
require a call into the clocksource driver to return a high-resolution
timestamp. This may have undesired side-effects in the debugger,
since we want to limit the interactions with the rest of the kernel.
- Adding a ktime_get_real_fast_seconds() based on tk_fast_mono
plus tkr->base_real without the tk_clock_read() delta. Not sure about
the value of adding yet another interface here.
- Changing the existing ktime_get_real_seconds() to use
tk_fast_mono on 32-bit architectures rather than xtime_sec. I think
this could work, but am not entirely sure if this is an improvement.
I picked the first of those for simplicity here. It's technically
not correct but probably good enough as the time is only used for the
debugging output and the race will likely never be hit in practice.
Another downside is having to move the declaration into a public header
file.
Let me know if anyone has a different preference.
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patchwork.kernel.org/patch/9775309/
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
2017-10-12 22:06:11 +08:00
|
|
|
extern time64_t __ktime_get_real_seconds(void);
|
2014-10-29 18:31:50 +08:00
|
|
|
extern time64_t ktime_get_real_seconds(void);
|
2018-03-02 00:33:32 +08:00
|
|
|
extern void ktime_get_active_ts64(struct timespec64 *ts);
|
2014-07-17 05:04:04 +08:00
|
|
|
|
|
|
|
|
extern int __getnstimeofday64(struct timespec64 *tv);
|
|
|
|
|
extern void getnstimeofday64(struct timespec64 *tv);
|
2014-12-09 04:00:09 +08:00
|
|
|
extern void getboottime64(struct timespec64 *ts);
|
2014-07-17 05:04:04 +08:00
|
|
|
|
2018-03-02 00:33:35 +08:00
|
|
|
#define ktime_get_real_ts64(ts) getnstimeofday64(ts)
|
|
|
|
|
|
|
|
|
|
/* Clock BOOTTIME compatibility wrappers */
|
|
|
|
|
static inline void get_monotonic_boottime64(struct timespec64 *ts)
|
|
|
|
|
{
|
|
|
|
|
ktime_get_ts64(ts);
|
|
|
|
|
}
|
2014-07-17 05:04:02 +08:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* ktime_t based interfaces
|
|
|
|
|
*/
|
2014-07-17 05:04:13 +08:00
|
|
|
enum tk_offsets {
|
|
|
|
|
TK_OFFS_REAL,
|
|
|
|
|
TK_OFFS_TAI,
|
|
|
|
|
TK_OFFS_MAX,
|
|
|
|
|
};
|
|
|
|
|
|
2014-07-17 05:04:02 +08:00
|
|
|
extern ktime_t ktime_get(void);
|
2014-07-17 05:04:13 +08:00
|
|
|
extern ktime_t ktime_get_with_offset(enum tk_offsets offs);
|
2014-07-17 05:04:22 +08:00
|
|
|
extern ktime_t ktime_mono_to_any(ktime_t tmono, enum tk_offsets offs);
|
2014-07-17 05:05:04 +08:00
|
|
|
extern ktime_t ktime_get_raw(void);
|
2015-04-07 19:12:35 +08:00
|
|
|
extern u32 ktime_get_resolution_ns(void);
|
2014-07-17 05:04:02 +08:00
|
|
|
|
2018-03-02 00:33:35 +08:00
|
|
|
/* Clock BOOTTIME compatibility wrappers */
|
|
|
|
|
static inline ktime_t ktime_get_boottime(void) { return ktime_get(); }
|
|
|
|
|
static inline u64 ktime_get_boot_ns(void) { return ktime_get(); }
|
|
|
|
|
|
2014-07-17 05:04:14 +08:00
|
|
|
/**
|
|
|
|
|
* ktime_get_real - get the real (wall-) time in ktime_t format
|
|
|
|
|
*/
|
|
|
|
|
static inline ktime_t ktime_get_real(void)
|
|
|
|
|
{
|
|
|
|
|
return ktime_get_with_offset(TK_OFFS_REAL);
|
|
|
|
|
}
|
|
|
|
|
|
2014-07-17 05:04:17 +08:00
|
|
|
/**
|
|
|
|
|
* ktime_get_clocktai - Returns the TAI time of day in ktime_t format
|
|
|
|
|
*/
|
|
|
|
|
static inline ktime_t ktime_get_clocktai(void)
|
|
|
|
|
{
|
|
|
|
|
return ktime_get_with_offset(TK_OFFS_TAI);
|
|
|
|
|
}
|
|
|
|
|
|
2014-07-17 05:04:22 +08:00
|
|
|
/**
|
|
|
|
|
* ktime_mono_to_real - Convert monotonic time to clock realtime
|
|
|
|
|
*/
|
|
|
|
|
static inline ktime_t ktime_mono_to_real(ktime_t mono)
|
|
|
|
|
{
|
|
|
|
|
return ktime_mono_to_any(mono, TK_OFFS_REAL);
|
|
|
|
|
}
|
|
|
|
|
|
2014-07-17 05:04:29 +08:00
|
|
|
static inline u64 ktime_get_ns(void)
|
|
|
|
|
{
|
|
|
|
|
return ktime_to_ns(ktime_get());
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline u64 ktime_get_real_ns(void)
|
|
|
|
|
{
|
|
|
|
|
return ktime_to_ns(ktime_get_real());
|
|
|
|
|
}
|
|
|
|
|
|
2015-03-17 19:39:10 +08:00
|
|
|
static inline u64 ktime_get_tai_ns(void)
|
|
|
|
|
{
|
|
|
|
|
return ktime_to_ns(ktime_get_clocktai());
|
|
|
|
|
}
|
|
|
|
|
|
2014-07-17 05:05:04 +08:00
|
|
|
static inline u64 ktime_get_raw_ns(void)
|
|
|
|
|
{
|
|
|
|
|
return ktime_to_ns(ktime_get_raw());
|
|
|
|
|
}
|
|
|
|
|
|
2014-07-17 05:05:23 +08:00
|
|
|
extern u64 ktime_get_mono_fast_ns(void);
|
2015-03-19 16:39:08 +08:00
|
|
|
extern u64 ktime_get_raw_fast_ns(void);
|
2017-08-31 23:12:48 +08:00
|
|
|
extern u64 ktime_get_real_fast_ns(void);
|
2014-07-17 05:05:23 +08:00
|
|
|
|
2018-03-02 00:33:35 +08:00
|
|
|
/*
|
|
|
|
|
* timespec64 interfaces utilizing the ktime based ones
|
|
|
|
|
*/
|
2017-03-27 03:04:14 +08:00
|
|
|
static inline void timekeeping_clocktai64(struct timespec64 *ts)
|
|
|
|
|
{
|
|
|
|
|
*ts = ktime_to_timespec64(ktime_get_clocktai());
|
|
|
|
|
}
|
|
|
|
|
|
2014-07-17 05:04:02 +08:00
|
|
|
/*
|
|
|
|
|
* RTC specific
|
|
|
|
|
*/
|
2015-04-02 11:34:38 +08:00
|
|
|
extern bool timekeeping_rtc_skipsuspend(void);
|
|
|
|
|
extern bool timekeeping_rtc_skipresume(void);
|
|
|
|
|
|
2014-11-18 19:15:17 +08:00
|
|
|
extern void timekeeping_inject_sleeptime64(struct timespec64 *delta);
|
|
|
|
|
|
2016-02-22 19:15:20 +08:00
|
|
|
/*
|
|
|
|
|
* struct system_time_snapshot - simultaneous raw/real time capture with
|
|
|
|
|
* counter value
|
|
|
|
|
* @cycles: Clocksource counter value to produce the system times
|
|
|
|
|
* @real: Realtime system time
|
|
|
|
|
* @raw: Monotonic raw system time
|
time: Add history to cross timestamp interface supporting slower devices
Another representative use case of time sync and the correlated
clocksource (in addition to PTP noted above) is PTP synchronized
audio.
In a streaming application, as an example, samples will be sent and/or
received by multiple devices with a presentation time that is in terms
of the PTP master clock. Synchronizing the audio output on these
devices requires correlating the audio clock with the PTP master
clock. The more precise this correlation is, the better the audio
quality (i.e. out of sync audio sounds bad).
From an application standpoint, to correlate the PTP master clock with
the audio device clock, the system clock is used as a intermediate
timebase. The transforms such an application would perform are:
System Clock <-> Audio clock
System Clock <-> Network Device Clock [<-> PTP Master Clock]
Modern Intel platforms can perform a more accurate cross timestamp in
hardware (ART,audio device clock). The audio driver requires
ART->system time transforms -- the same as required for the network
driver. These platforms offload audio processing (including
cross-timestamps) to a DSP which to ensure uninterrupted audio
processing, communicates and response to the host only once every
millsecond. As a result is takes up to a millisecond for the DSP to
receive a request, the request is processed by the DSP, the audio
output hardware is polled for completion, the result is copied into
shared memory, and the host is notified. All of these operation occur
on a millisecond cadence. This transaction requires about 2 ms, but
under heavier workloads it may take up to 4 ms.
Adding a history allows these slow devices the option of providing an
ART value outside of the current interval. In this case, the callback
provided is an accessor function for the previously obtained counter
value. If get_system_device_crosststamp() receives a counter value
previous to cycle_last, it consults the history provided as an
argument in history_ref and interpolates the realtime and monotonic
raw system time using the provided counter value. If there are any
clock discontinuities, e.g. from calling settimeofday(), the monotonic
raw time is interpolated in the usual way, but the realtime clock time
is adjusted by scaling the monotonic raw adjustment.
When an accessor function is used a history argument *must* be
provided. The history is initialized using ktime_get_snapshot() and
must be called before the counter values are read.
Cc: Prarit Bhargava <prarit@redhat.com>
Cc: Richard Cochran <richardcochran@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: kevin.b.stanton@intel.com
Cc: kevin.j.clarke@intel.com
Cc: hpa@zytor.com
Cc: jeffrey.t.kirsher@intel.com
Cc: netdev@vger.kernel.org
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Christopher S. Hall <christopher.s.hall@intel.com>
[jstultz: Fixed up cycles_t/cycle_t type confusion]
Signed-off-by: John Stultz <john.stultz@linaro.org>
2016-02-22 19:15:23 +08:00
|
|
|
* @clock_was_set_seq: The sequence number of clock was set events
|
|
|
|
|
* @cs_was_changed_seq: The sequence number of clocksource change events
|
2016-02-22 19:15:20 +08:00
|
|
|
*/
|
|
|
|
|
struct system_time_snapshot {
|
2016-12-22 03:32:01 +08:00
|
|
|
u64 cycles;
|
2016-02-22 19:15:20 +08:00
|
|
|
ktime_t real;
|
|
|
|
|
ktime_t raw;
|
time: Add history to cross timestamp interface supporting slower devices
Another representative use case of time sync and the correlated
clocksource (in addition to PTP noted above) is PTP synchronized
audio.
In a streaming application, as an example, samples will be sent and/or
received by multiple devices with a presentation time that is in terms
of the PTP master clock. Synchronizing the audio output on these
devices requires correlating the audio clock with the PTP master
clock. The more precise this correlation is, the better the audio
quality (i.e. out of sync audio sounds bad).
From an application standpoint, to correlate the PTP master clock with
the audio device clock, the system clock is used as a intermediate
timebase. The transforms such an application would perform are:
System Clock <-> Audio clock
System Clock <-> Network Device Clock [<-> PTP Master Clock]
Modern Intel platforms can perform a more accurate cross timestamp in
hardware (ART,audio device clock). The audio driver requires
ART->system time transforms -- the same as required for the network
driver. These platforms offload audio processing (including
cross-timestamps) to a DSP which to ensure uninterrupted audio
processing, communicates and response to the host only once every
millsecond. As a result is takes up to a millisecond for the DSP to
receive a request, the request is processed by the DSP, the audio
output hardware is polled for completion, the result is copied into
shared memory, and the host is notified. All of these operation occur
on a millisecond cadence. This transaction requires about 2 ms, but
under heavier workloads it may take up to 4 ms.
Adding a history allows these slow devices the option of providing an
ART value outside of the current interval. In this case, the callback
provided is an accessor function for the previously obtained counter
value. If get_system_device_crosststamp() receives a counter value
previous to cycle_last, it consults the history provided as an
argument in history_ref and interpolates the realtime and monotonic
raw system time using the provided counter value. If there are any
clock discontinuities, e.g. from calling settimeofday(), the monotonic
raw time is interpolated in the usual way, but the realtime clock time
is adjusted by scaling the monotonic raw adjustment.
When an accessor function is used a history argument *must* be
provided. The history is initialized using ktime_get_snapshot() and
must be called before the counter values are read.
Cc: Prarit Bhargava <prarit@redhat.com>
Cc: Richard Cochran <richardcochran@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: kevin.b.stanton@intel.com
Cc: kevin.j.clarke@intel.com
Cc: hpa@zytor.com
Cc: jeffrey.t.kirsher@intel.com
Cc: netdev@vger.kernel.org
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Christopher S. Hall <christopher.s.hall@intel.com>
[jstultz: Fixed up cycles_t/cycle_t type confusion]
Signed-off-by: John Stultz <john.stultz@linaro.org>
2016-02-22 19:15:23 +08:00
|
|
|
unsigned int clock_was_set_seq;
|
|
|
|
|
u8 cs_was_changed_seq;
|
2016-02-22 19:15:20 +08:00
|
|
|
};
|
|
|
|
|
|
2016-02-22 19:15:22 +08:00
|
|
|
/*
|
|
|
|
|
* struct system_device_crosststamp - system/device cross-timestamp
|
|
|
|
|
* (syncronized capture)
|
|
|
|
|
* @device: Device time
|
|
|
|
|
* @sys_realtime: Realtime simultaneous with device time
|
|
|
|
|
* @sys_monoraw: Monotonic raw simultaneous with device time
|
|
|
|
|
*/
|
|
|
|
|
struct system_device_crosststamp {
|
|
|
|
|
ktime_t device;
|
|
|
|
|
ktime_t sys_realtime;
|
|
|
|
|
ktime_t sys_monoraw;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* struct system_counterval_t - system counter value with the pointer to the
|
|
|
|
|
* corresponding clocksource
|
|
|
|
|
* @cycles: System counter value
|
|
|
|
|
* @cs: Clocksource corresponding to system counter value. Used by
|
|
|
|
|
* timekeeping code to verify comparibility of two cycle values
|
|
|
|
|
*/
|
|
|
|
|
struct system_counterval_t {
|
2016-12-22 03:32:01 +08:00
|
|
|
u64 cycles;
|
2016-02-22 19:15:22 +08:00
|
|
|
struct clocksource *cs;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Get cross timestamp between system clock and device clock
|
|
|
|
|
*/
|
|
|
|
|
extern int get_device_system_crosststamp(
|
|
|
|
|
int (*get_time_fn)(ktime_t *device_time,
|
|
|
|
|
struct system_counterval_t *system_counterval,
|
|
|
|
|
void *ctx),
|
|
|
|
|
void *ctx,
|
time: Add history to cross timestamp interface supporting slower devices
Another representative use case of time sync and the correlated
clocksource (in addition to PTP noted above) is PTP synchronized
audio.
In a streaming application, as an example, samples will be sent and/or
received by multiple devices with a presentation time that is in terms
of the PTP master clock. Synchronizing the audio output on these
devices requires correlating the audio clock with the PTP master
clock. The more precise this correlation is, the better the audio
quality (i.e. out of sync audio sounds bad).
From an application standpoint, to correlate the PTP master clock with
the audio device clock, the system clock is used as a intermediate
timebase. The transforms such an application would perform are:
System Clock <-> Audio clock
System Clock <-> Network Device Clock [<-> PTP Master Clock]
Modern Intel platforms can perform a more accurate cross timestamp in
hardware (ART,audio device clock). The audio driver requires
ART->system time transforms -- the same as required for the network
driver. These platforms offload audio processing (including
cross-timestamps) to a DSP which to ensure uninterrupted audio
processing, communicates and response to the host only once every
millsecond. As a result is takes up to a millisecond for the DSP to
receive a request, the request is processed by the DSP, the audio
output hardware is polled for completion, the result is copied into
shared memory, and the host is notified. All of these operation occur
on a millisecond cadence. This transaction requires about 2 ms, but
under heavier workloads it may take up to 4 ms.
Adding a history allows these slow devices the option of providing an
ART value outside of the current interval. In this case, the callback
provided is an accessor function for the previously obtained counter
value. If get_system_device_crosststamp() receives a counter value
previous to cycle_last, it consults the history provided as an
argument in history_ref and interpolates the realtime and monotonic
raw system time using the provided counter value. If there are any
clock discontinuities, e.g. from calling settimeofday(), the monotonic
raw time is interpolated in the usual way, but the realtime clock time
is adjusted by scaling the monotonic raw adjustment.
When an accessor function is used a history argument *must* be
provided. The history is initialized using ktime_get_snapshot() and
must be called before the counter values are read.
Cc: Prarit Bhargava <prarit@redhat.com>
Cc: Richard Cochran <richardcochran@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: kevin.b.stanton@intel.com
Cc: kevin.j.clarke@intel.com
Cc: hpa@zytor.com
Cc: jeffrey.t.kirsher@intel.com
Cc: netdev@vger.kernel.org
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Christopher S. Hall <christopher.s.hall@intel.com>
[jstultz: Fixed up cycles_t/cycle_t type confusion]
Signed-off-by: John Stultz <john.stultz@linaro.org>
2016-02-22 19:15:23 +08:00
|
|
|
struct system_time_snapshot *history,
|
2016-02-22 19:15:22 +08:00
|
|
|
struct system_device_crosststamp *xtstamp);
|
|
|
|
|
|
2016-02-22 19:15:20 +08:00
|
|
|
/*
|
|
|
|
|
* Simultaneously snapshot realtime and monotonic raw clocks
|
|
|
|
|
*/
|
|
|
|
|
extern void ktime_get_snapshot(struct system_time_snapshot *systime_snapshot);
|
|
|
|
|
|
2014-07-17 05:04:02 +08:00
|
|
|
/*
|
|
|
|
|
* Persistent clock related interfaces
|
|
|
|
|
*/
|
|
|
|
|
extern int persistent_clock_is_local;
|
|
|
|
|
|
2015-04-02 11:34:22 +08:00
|
|
|
extern void read_persistent_clock64(struct timespec64 *ts);
|
2015-04-02 11:34:21 +08:00
|
|
|
extern void read_boot_clock64(struct timespec64 *ts);
|
2015-04-02 11:34:23 +08:00
|
|
|
extern int update_persistent_clock64(struct timespec64 now);
|
2014-07-17 05:04:02 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
#endif
|