From: Vladimir Oltean <olteanv@gmail.com>
To: f.fainelli@gmail.com, vivien.didelot@gmail.com, andrew@lunn.ch,
davem@davemloft.net, richardcochran@gmail.com,
john.stultz@linaro.org, tglx@linutronix.de, sboyd@kernel.org
Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
Vladimir Oltean <olteanv@gmail.com>
Subject: [PATCH net-next 1/5] timecounter: Add helper for reconstructing partial timestamps
Date: Wed, 29 May 2019 02:56:23 +0300 [thread overview]
Message-ID: <20190528235627.1315-2-olteanv@gmail.com> (raw)
In-Reply-To: <20190528235627.1315-1-olteanv@gmail.com>
Some PTP hardware offers a 64-bit free-running counter whose snapshots
are used for timestamping, but only makes part of that snapshot
available as timestamps (low-order bits).
In that case, timecounter/cyclecounter users must bring the cyclecounter
and timestamps to the same bit width, and they currently have two
options of doing so:
- Trim the higher bits of the timecounter itself to the number of bits
of the timestamps. This might work for some setups, but if the
wraparound of the timecounter in this case becomes high (~10 times per
second) then this causes additional strain on the system, which must
read the clock that often just to avoid missing the wraparounds.
- Reconstruct the timestamp by racing to read the PTP time within one
wraparound cycle since the timestamp was generated. This is
preferable when the wraparound time is small (do a time-critical
readout once vs doing it periodically), and it has no drawback even
when the wraparound is comfortably sized.
Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
---
include/linux/timecounter.h | 7 +++++++
kernel/time/timecounter.c | 33 +++++++++++++++++++++++++++++++++
2 files changed, 40 insertions(+)
diff --git a/include/linux/timecounter.h b/include/linux/timecounter.h
index 2496ad4cfc99..03eab1f3bb9c 100644
--- a/include/linux/timecounter.h
+++ b/include/linux/timecounter.h
@@ -30,6 +30,9 @@
* by the implementor and user of specific instances of this API.
*
* @read: returns the current cycle value
+ * @partial_tstamp_mask:bitmask in case the hardware emits timestamps
+ * which only capture low-order bits of the full
+ * counter, and should be reconstructed.
* @mask: bitmask for two's complement
* subtraction of non 64 bit counters,
* see CYCLECOUNTER_MASK() helper macro
@@ -38,6 +41,7 @@
*/
struct cyclecounter {
u64 (*read)(const struct cyclecounter *cc);
+ u64 partial_tstamp_mask;
u64 mask;
u32 mult;
u32 shift;
@@ -136,4 +140,7 @@ extern u64 timecounter_read(struct timecounter *tc);
extern u64 timecounter_cyc2time(struct timecounter *tc,
u64 cycle_tstamp);
+extern u64 cyclecounter_reconstruct(const struct cyclecounter *cc,
+ u64 ts_partial);
+
#endif
diff --git a/kernel/time/timecounter.c b/kernel/time/timecounter.c
index 85b98e727306..d4657d64e38d 100644
--- a/kernel/time/timecounter.c
+++ b/kernel/time/timecounter.c
@@ -97,3 +97,36 @@ u64 timecounter_cyc2time(struct timecounter *tc,
return nsec;
}
EXPORT_SYMBOL_GPL(timecounter_cyc2time);
+
+/**
+ * cyclecounter_reconstruct - reconstructs @ts_partial
+ * @cc: Pointer to cycle counter.
+ * @ts_partial: Typically RX or TX NIC timestamp, provided by hardware as
+ * the lower @partial_tstamp_mask bits of the cycle counter,
+ * sampled at the time the timestamp was collected.
+ * To reconstruct into a full @mask bit-wide timestamp, the
+ * cycle counter is read and the high-order bits (up to @mask) are
+ * filled in.
+ * Must be called within one wraparound of @partial_tstamp_mask
+ * bits of the cycle counter.
+ */
+u64 cyclecounter_reconstruct(const struct cyclecounter *cc, u64 ts_partial)
+{
+ u64 ts_reconstructed;
+ u64 cycle_now;
+
+ cycle_now = cc->read(cc);
+
+ ts_reconstructed = (cycle_now & ~cc->partial_tstamp_mask) |
+ ts_partial;
+
+ /* Check lower bits of current cycle counter against the timestamp.
+ * If the current cycle counter is lower than the partial timestamp,
+ * then wraparound surely occurred and must be accounted for.
+ */
+ if ((cycle_now & cc->partial_tstamp_mask) <= ts_partial)
+ ts_reconstructed -= (cc->partial_tstamp_mask + 1);
+
+ return ts_reconstructed;
+}
+EXPORT_SYMBOL_GPL(cyclecounter_reconstruct);
--
2.17.1
next prev parent reply other threads:[~2019-05-28 23:58 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-28 23:56 [PATCH net-next 0/5] PTP support for the SJA1105 DSA driver Vladimir Oltean
2019-05-28 23:56 ` Vladimir Oltean [this message]
2019-05-29 2:14 ` [PATCH net-next 1/5] timecounter: Add helper for reconstructing partial timestamps John Stultz
2019-05-29 4:40 ` Richard Cochran
2019-05-29 20:23 ` Vladimir Oltean
2019-05-28 23:56 ` [PATCH net-next 2/5] net: dsa: sja1105: Add support for the PTP clock Vladimir Oltean
2019-05-28 23:56 ` [PATCH net-next 3/5] net: dsa: mv88e6xxx: Let taggers specify a can_timestamp function Vladimir Oltean
2019-05-29 4:49 ` Richard Cochran
2019-05-29 20:33 ` Vladimir Oltean
2019-05-30 3:51 ` Richard Cochran
2019-05-30 7:42 ` Vladimir Oltean
2019-05-30 14:23 ` Richard Cochran
2019-05-30 14:40 ` Richard Cochran
2019-05-30 14:47 ` Vladimir Oltean
2019-05-30 15:01 ` Richard Cochran
2019-11-19 11:35 ` Design issue in DSA RX timestamping (Was "Re: [PATCH net-next 3/5] net: dsa: mv88e6xxx: Let taggers specify a can_timestamp function") Vladimir Oltean
2019-11-19 14:03 ` Richard Cochran
2019-05-28 23:56 ` [PATCH net-next 4/5] net: dsa: sja1105: Add support for PTP timestamping Vladimir Oltean
2019-05-28 23:56 ` [PATCH net-next 5/5] net: dsa: sja1105: Increase priority of CPU-trapped frames Vladimir Oltean
2019-05-29 4:52 ` [PATCH net-next 0/5] PTP support for the SJA1105 DSA driver Richard Cochran
2019-05-29 20:41 ` Vladimir Oltean
2019-05-30 3:45 ` Richard Cochran
2019-05-30 9:01 ` Vladimir Oltean
2019-05-30 14:30 ` Richard Cochran
2019-05-30 14:57 ` Vladimir Oltean
2019-05-30 15:05 ` Richard Cochran
2019-05-30 15:23 ` Vladimir Oltean
2019-05-31 4:34 ` Richard Cochran
2019-05-31 13:23 ` Vladimir Oltean
2019-05-31 14:08 ` Richard Cochran
2019-05-31 14:27 ` Vladimir Oltean
2019-05-31 15:11 ` Richard Cochran
2019-05-31 15:21 ` Richard Cochran
2019-05-31 15:23 ` Vladimir Oltean
2019-05-31 16:09 ` Richard Cochran
2019-05-31 16:16 ` Vladimir Oltean
2019-05-31 18:12 ` Vladimir Oltean
2019-06-01 5:07 ` Richard Cochran
2019-06-01 10:31 ` Vladimir Oltean
2019-06-01 12:06 ` Vladimir Oltean
2019-06-02 2:18 ` Richard Cochran
2019-06-02 2:17 ` Richard Cochran
2019-06-01 5:03 ` Richard Cochran
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=20190528235627.1315-2-olteanv@gmail.com \
--to=olteanv@gmail.com \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=f.fainelli@gmail.com \
--cc=john.stultz@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=richardcochran@gmail.com \
--cc=sboyd@kernel.org \
--cc=tglx@linutronix.de \
--cc=vivien.didelot@gmail.com \
/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;
as well as URLs for NNTP newsgroup(s).