From: Vladimir Oltean <olteanv@gmail.com>
To: kuba@kernel.org, davem@davemloft.net, netdev@vger.kernel.org
Cc: richardcochran@gmail.com, jacob.e.keller@intel.com,
yangbo.lu@nxp.com, xiaoliang.yang_1@nxp.com, po.liu@nxp.com,
UNGLinuxDriver@microchip.com
Subject: [PATCH v2 net-next 2/3] ptp: introduce a phase offset in the periodic output request
Date: Fri, 17 Jul 2020 01:45:30 +0300 [thread overview]
Message-ID: <20200716224531.1040140-3-olteanv@gmail.com> (raw)
In-Reply-To: <20200716224531.1040140-1-olteanv@gmail.com>
Some PHCs like the ocelot/felix switch cannot emit generic periodic
output, but just PPS (pulse per second) signals, which:
- don't start from arbitrary absolute times, but are rather
phase-aligned to the beginning of [the closest next] second.
- have an optional phase offset relative to that beginning of the
second.
For those, it was initially established that they should reject any
other absolute time for the PTP_PEROUT_REQUEST than 0.000000000 [1].
But when it actually came to writing an application [2] that makes use
of this functionality, we realized that we can't really deal generically
with PHCs that support absolute start time, and with PHCs that don't,
without an explicit interface. Namely, in an ideal world, PHC drivers
would ensure that the "perout.start" value written to hardware will
result in a functional output. This means that if the PTP time has
become in the past of this PHC's current time, it should be
automatically fast-forwarded by the driver into a close enough future
time that is known to work (note: this is necessary only if the hardware
doesn't do this fast-forward by itself). But we don't really know what
is the status for PHC drivers in use today, so in the general sense,
user space would be risking to have a non-functional periodic output if
it simply asked for a start time of 0.000000000.
So let's introduce a flag for this type of reduced-functionality
hardware, named PTP_PEROUT_PHASE. The start time is just "soon", the
only thing we know for sure about this signal is that its rising edge
events, Rn, occur at:
Rn = perout.phase + n * perout.period
The "phase" in the periodic output structure is simply an alias to the
"start" time, since both cannot logically be specified at the same time.
Therefore, the binary layout of the structure is not affected.
[1]: https://patchwork.ozlabs.org/project/netdev/patch/20200320103726.32559-7-yangbo.lu@nxp.com/
[2]: https://www.mail-archive.com/linuxptp-devel@lists.sourceforge.net/msg04142.html
Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
---
Changes in v2:
Typo in commit message: period -> perout
include/uapi/linux/ptp_clock.h | 19 +++++++++++++++++--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/include/uapi/linux/ptp_clock.h b/include/uapi/linux/ptp_clock.h
index 1d2841155f7d..1d108d597f66 100644
--- a/include/uapi/linux/ptp_clock.h
+++ b/include/uapi/linux/ptp_clock.h
@@ -55,12 +55,14 @@
*/
#define PTP_PEROUT_ONE_SHOT (1<<0)
#define PTP_PEROUT_DUTY_CYCLE (1<<1)
+#define PTP_PEROUT_PHASE (1<<2)
/*
* flag fields valid for the new PTP_PEROUT_REQUEST2 ioctl.
*/
#define PTP_PEROUT_VALID_FLAGS (PTP_PEROUT_ONE_SHOT | \
- PTP_PEROUT_DUTY_CYCLE)
+ PTP_PEROUT_DUTY_CYCLE | \
+ PTP_PEROUT_PHASE)
/*
* No flags are valid for the original PTP_PEROUT_REQUEST ioctl
@@ -103,7 +105,20 @@ struct ptp_extts_request {
};
struct ptp_perout_request {
- struct ptp_clock_time start; /* Absolute start time. */
+ union {
+ /*
+ * Absolute start time.
+ * Valid only if (flags & PTP_PEROUT_PHASE) is unset.
+ */
+ struct ptp_clock_time start;
+ /*
+ * Phase offset. The signal should start toggling at an
+ * unspecified integer multiple of the period, plus this value.
+ * The start time should be "as soon as possible".
+ * Valid only if (flags & PTP_PEROUT_PHASE) is set.
+ */
+ struct ptp_clock_time phase;
+ };
struct ptp_clock_time period; /* Desired period, zero means disable. */
unsigned int index; /* Which channel to configure. */
unsigned int flags;
--
2.25.1
next prev parent reply other threads:[~2020-07-16 23:10 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-16 22:45 [PATCH v2 net-next 0/3] Fully describe the waveform for PTP periodic output Vladimir Oltean
2020-07-16 22:45 ` [PATCH v2 net-next 1/3] ptp: add ability to configure duty cycle for " Vladimir Oltean
2020-07-16 22:45 ` Vladimir Oltean [this message]
2020-07-16 22:45 ` [PATCH v2 net-next 3/3] net: mscc: ocelot: add support for PTP waveform configuration Vladimir Oltean
2020-07-17 13:43 ` Horatiu Vultur
2020-07-20 2:24 ` [PATCH v2 net-next 0/3] Fully describe the waveform for PTP periodic output David Miller
2020-07-20 14:11 ` 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=20200716224531.1040140-3-olteanv@gmail.com \
--to=olteanv@gmail.com \
--cc=UNGLinuxDriver@microchip.com \
--cc=davem@davemloft.net \
--cc=jacob.e.keller@intel.com \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=po.liu@nxp.com \
--cc=richardcochran@gmail.com \
--cc=xiaoliang.yang_1@nxp.com \
--cc=yangbo.lu@nxp.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).