From: Thomas Gleixner <tglx@linutronix.de>
To: "Christopher S. Hall" <christopher.s.hall@intel.com>
Cc: jeffrey.t.kirsher@intel.com, hpa@zytor.com, mingo@redhat.com,
john.stultz@linaro.org, richardcochran@gmail.com, x86@kernel.org,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
intel-wired-lan@lists.osuosl.org, peterz@infradead.org
Subject: Re: [PATCH v3 1/4] Add correlated clocksource deriving system time from an auxiliary clocksource
Date: Sat, 22 Aug 2015 22:17:00 +0200 (CEST) [thread overview]
Message-ID: <alpine.DEB.2.11.1508222143530.3873@nanos> (raw)
In-Reply-To: <1440183128-1384-2-git-send-email-christopher.s.hall@intel.com>
On Fri, 21 Aug 2015, Christopher S. Hall wrote:
> Add struct correlated_cs with pointer to original clocksource and
> function pointer to convert correlated clocksource to the original
>
> Add get_correlated_timestamp() function which given specific correlated_cs
> and correlated_ts convert correlated counter value to system time
This is not a proper changelog.
1) The subject line lacks a subsystem prefix
timekeeping:
Is the proper choice here
2) The subject line should be short and precise
timekeeping: Add mechanism to gather correlated timestamps
Might be an informative one.
3) The changelog itself should describe the reason why we want this
change, the purpose of the change etc.
Add foo
Add bar
Is pointless because we can see that from the patch itself.
What the patch cannot not explain is the WHY. That's what the
changelog is for.
4) You dropped the authorship
The proper way to do this is to add a 'FROM: author' at the top of
the changelog body.
As I wrote the patch, so I give you a changelog along with it:
<---
Subject: timekeeping: Add mechanism to gather correlated timestamps
From: Thomas Gleixner <tglx@linutronix.de>
Modern Intel hardware provides the so called Always Running Timer
(ART). The TSC which is usually used for timekeeping is derived from
ART and runs with a fixed frequency ratio to it. ART is routed to
devices and allows to take atomic timestamp samples from the device
clock and the ART. One use case is PTP timestamps on network cards. We
want to utilize this feature as it allows us to better correlate the
PTP timestamp to the system time.
In order to gather precise timestamps we need to make sure that the
conversion from ART to TSC and the following conversion from TSC to
clock realtime happens synchronized with the ongoing timekeeping
updates. Otherwise we might convert an ART timestamp from point A in
time with the conversion factors of point B in time. These conversion
factors can differ due to NTP/PTP frequency adjustments and therefor
the resulting clock realtime timestamp would be slightly off, which is
contrary to the whole purpose of synchronized hardware timestamps.
Provide data structures which describe the correlation between two
clocksources and a function to gather correlated and convert
timestamps from a device. The function is as any other timekeeping
function protected against current timekeeper updates via the
timekeeper sequence lock. It calls the device function to gather the
hardware timestamps and converts them to clock real time and clock
monotonic raw.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---->
Can you see the difference?
> Signed-off-by: Christopher S. Hall <christopher.s.hall@intel.com>
> ---
> include/linux/clocksource.h | 33 +++++++++++++++++++++++
> include/linux/timekeeping.h | 4 +++
> kernel/time/timekeeping.c | 65 +++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 102 insertions(+)
>
> diff --git a/include/linux/clocksource.h b/include/linux/clocksource.h
> index 278dd27..4bedadb 100644
> --- a/include/linux/clocksource.h
> +++ b/include/linux/clocksource.h
> @@ -258,4 +258,37 @@ void acpi_generic_timer_init(void);
> static inline void acpi_generic_timer_init(void) { }
> #endif
>
> +/*
> + * struct correlated_cs - Descriptor for a clocksource correlated to another
> + * clocksource
Don't believe checkpatch here. KernelDoc requires that this is one
line, 80 char limit or not.
> /**
> + * get_correlated_timestamp - Get a correlated timestamp
> + *
Lacks the parameter documentation:
* @crt: Pointer to a correlated timestamp structure which provides
* the device specific timestamp function and is used to store
* the raw and the correlated timestamps.
* @crs: Pointer to a correlated clocksource structure which describes
* the correlated clocksource and provides a conversion function
* to the timekeeping clocksource
> + return 0;
> +}
> +EXPORT_SYMBOL(get_correlated_timestamp);
EXPORT_SYMBOL_GPL please.
Thanks,
tglx
next prev parent reply other threads:[~2015-08-22 20:17 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-21 18:52 [PATCH v3 0/4] Patchset enabling hardware based cross-timestamps for next gen Intel platforms Christopher S. Hall
2015-08-21 18:52 ` [PATCH v3 1/4] Add correlated clocksource deriving system time from an auxiliary clocksource Christopher S. Hall
2015-08-22 20:17 ` Thomas Gleixner [this message]
2015-09-03 23:20 ` Hall, Christopher S
2015-09-04 8:11 ` Richard Cochran
2015-09-04 14:28 ` Peter Zijlstra
2015-09-04 21:12 ` Hall, Christopher S
2015-09-04 13:02 ` Thomas Gleixner
2015-09-04 15:10 ` Peter Zijlstra
2015-09-04 15:17 ` Richard Cochran
2015-09-04 15:41 ` Peter Zijlstra
2015-09-04 16:35 ` Thomas Gleixner
2015-09-04 21:01 ` Hall, Christopher S
2015-09-05 8:46 ` Thomas Gleixner
2015-09-05 10:04 ` Ingo Molnar
2015-09-04 15:32 ` Richard Cochran
2015-09-04 21:50 ` John Stultz
2015-08-21 18:52 ` [PATCH v3 2/4] Added ART correlated clocksource and ART CPU feature Christopher S. Hall
2015-08-22 20:26 ` Thomas Gleixner
2015-08-21 18:52 ` [PATCH v3 3/4] Add support for driver cross-timestamp to PTP_SYS_OFFSET ioctl Christopher S. Hall
2015-08-22 20:33 ` Thomas Gleixner
2015-08-22 21:17 ` Richard Cochran
2015-08-23 8:15 ` Thomas Gleixner
2015-08-23 11:25 ` Richard Cochran
2015-08-24 20:16 ` Hall, Christopher S
2015-08-25 7:31 ` Richard Cochran
2015-08-21 18:52 ` [PATCH v3 4/4] Enabling hardware supported PTP system/device crosstimestamping Christopher S. Hall
2015-08-22 20:46 ` Thomas Gleixner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.2.11.1508222143530.3873@nanos \
--to=tglx@linutronix.de \
--cc=christopher.s.hall@intel.com \
--cc=hpa@zytor.com \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=jeffrey.t.kirsher@intel.com \
--cc=john.stultz@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=richardcochran@gmail.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox