2017-11-01 22:09:13 +08:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0+ WITH Linux-syscall-note */
|
2011-04-22 18:03:08 +08:00
|
|
|
/*
|
|
|
|
|
* PTP 1588 clock support - user space interface
|
|
|
|
|
*
|
|
|
|
|
* Copyright (C) 2010 OMICRON electronics GmbH
|
|
|
|
|
*
|
|
|
|
|
* This program is free software; you can redistribute it and/or modify
|
|
|
|
|
* it under the terms of the GNU General Public License as published by
|
|
|
|
|
* the Free Software Foundation; either version 2 of the License, or
|
|
|
|
|
* (at your option) any later version.
|
|
|
|
|
*
|
|
|
|
|
* This program is distributed in the hope that it will be useful,
|
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
|
* GNU General Public License for more details.
|
|
|
|
|
*
|
|
|
|
|
* You should have received a copy of the GNU General Public License
|
|
|
|
|
* along with this program; if not, write to the Free Software
|
|
|
|
|
* Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#ifndef _PTP_CLOCK_H_
|
|
|
|
|
#define _PTP_CLOCK_H_
|
|
|
|
|
|
|
|
|
|
#include <linux/ioctl.h>
|
|
|
|
|
#include <linux/types.h>
|
|
|
|
|
|
2019-09-11 14:16:21 +08:00
|
|
|
/*
|
|
|
|
|
* Bits of the ptp_extts_request.flags field:
|
|
|
|
|
*/
|
2011-04-22 18:03:08 +08:00
|
|
|
#define PTP_ENABLE_FEATURE (1<<0)
|
|
|
|
|
#define PTP_RISING_EDGE (1<<1)
|
|
|
|
|
#define PTP_FALLING_EDGE (1<<2)
|
2019-11-15 02:45:02 +08:00
|
|
|
#define PTP_STRICT_FLAGS (1<<3)
|
2019-11-15 02:44:55 +08:00
|
|
|
#define PTP_EXTTS_EDGES (PTP_RISING_EDGE | PTP_FALLING_EDGE)
|
ptp: correctly disable flags on old ioctls
Commit 415606588c61 ("PTP: introduce new versions of IOCTLs",
2019-09-13) introduced new versions of the PTP ioctls which actually
validate that the flags are acceptable values.
As part of this, it cleared the flags value using a bitwise
and+negation, in an attempt to prevent the old ioctl from accidentally
enabling new features.
This is incorrect for a couple of reasons. First, it results in
accidentally preventing previously working flags on the request ioctl.
By clearing the "valid" flags, we now no longer allow setting the
enable, rising edge, or falling edge flags.
Second, if we add new additional flags in the future, they must not be
set by the old ioctl. (Since the flag wasn't checked before, we could
potentially break userspace programs which sent garbage flag data.
The correct way to resolve this is to check for and clear all but the
originally valid flags.
Create defines indicating which flags are correctly checked and
interpreted by the original ioctls. Use these to clear any bits which
will not be correctly interpreted by the original ioctls.
In the future, new flags must be added to the VALID_FLAGS macros, but
*not* to the V1_VALID_FLAGS macros. In this way, new features may be
exposed over the v2 ioctls, but without breaking previous userspace
which happened to not clear the flags value properly. The old ioctl will
continue to behave the same way, while the new ioctl gains the benefit
of using the flags fields.
Cc: Richard Cochran <richardcochran@gmail.com>
Cc: Felipe Balbi <felipe.balbi@linux.intel.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: Christopher Hall <christopher.s.hall@intel.com>
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Acked-by: Richard Cochran <richardcochran@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-09-26 10:28:19 +08:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* flag fields valid for the new PTP_EXTTS_REQUEST2 ioctl.
|
|
|
|
|
*/
|
2019-09-11 14:16:21 +08:00
|
|
|
#define PTP_EXTTS_VALID_FLAGS (PTP_ENABLE_FEATURE | \
|
|
|
|
|
PTP_RISING_EDGE | \
|
2019-11-15 02:45:02 +08:00
|
|
|
PTP_FALLING_EDGE | \
|
|
|
|
|
PTP_STRICT_FLAGS)
|
2019-09-11 14:16:21 +08:00
|
|
|
|
ptp: correctly disable flags on old ioctls
Commit 415606588c61 ("PTP: introduce new versions of IOCTLs",
2019-09-13) introduced new versions of the PTP ioctls which actually
validate that the flags are acceptable values.
As part of this, it cleared the flags value using a bitwise
and+negation, in an attempt to prevent the old ioctl from accidentally
enabling new features.
This is incorrect for a couple of reasons. First, it results in
accidentally preventing previously working flags on the request ioctl.
By clearing the "valid" flags, we now no longer allow setting the
enable, rising edge, or falling edge flags.
Second, if we add new additional flags in the future, they must not be
set by the old ioctl. (Since the flag wasn't checked before, we could
potentially break userspace programs which sent garbage flag data.
The correct way to resolve this is to check for and clear all but the
originally valid flags.
Create defines indicating which flags are correctly checked and
interpreted by the original ioctls. Use these to clear any bits which
will not be correctly interpreted by the original ioctls.
In the future, new flags must be added to the VALID_FLAGS macros, but
*not* to the V1_VALID_FLAGS macros. In this way, new features may be
exposed over the v2 ioctls, but without breaking previous userspace
which happened to not clear the flags value properly. The old ioctl will
continue to behave the same way, while the new ioctl gains the benefit
of using the flags fields.
Cc: Richard Cochran <richardcochran@gmail.com>
Cc: Felipe Balbi <felipe.balbi@linux.intel.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: Christopher Hall <christopher.s.hall@intel.com>
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Acked-by: Richard Cochran <richardcochran@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-09-26 10:28:19 +08:00
|
|
|
/*
|
|
|
|
|
* flag fields valid for the original PTP_EXTTS_REQUEST ioctl.
|
|
|
|
|
* DO NOT ADD NEW FLAGS HERE.
|
|
|
|
|
*/
|
|
|
|
|
#define PTP_EXTTS_V1_VALID_FLAGS (PTP_ENABLE_FEATURE | \
|
|
|
|
|
PTP_RISING_EDGE | \
|
|
|
|
|
PTP_FALLING_EDGE)
|
|
|
|
|
|
2019-09-11 14:16:21 +08:00
|
|
|
/*
|
|
|
|
|
* Bits of the ptp_perout_request.flags field:
|
|
|
|
|
*/
|
ptp: add ability to configure duty cycle for periodic output
There are external event timestampers (PHCs with support for
PTP_EXTTS_REQUEST) that timestamp both event edges.
When those edges are very close (such as in the case of a short pulse),
there is a chance that the collected timestamp might be of the rising,
or of the falling edge, we never know.
There are also PHCs capable of generating periodic output with a
configurable duty cycle. This is good news, because we can space the
rising and falling edge out enough in time, that the risks to overrun
the 1-entry timestamp FIFO of the extts PHC are lower (example: the
perout PHC can be configured for a period of 1 second, and an "on" time
of 0.5 seconds, resulting in a duty cycle of 50%).
A flag is introduced for signaling that an on time is present in the
perout request structure, for preserving compatibility. Logically
speaking, the duty cycle cannot exceed 100% and the PTP core checks for
this.
PHC drivers that don't support this flag emit a periodic output of an
unspecified duty cycle, same as before.
The duty cycle is encoded as an "on" time, similar to the "start" and
"period" times, and reuses the reserved space while preserving overall
binary layout.
Pahole reported before:
struct ptp_perout_request {
struct ptp_clock_time start; /* 0 16 */
struct ptp_clock_time period; /* 16 16 */
unsigned int index; /* 32 4 */
unsigned int flags; /* 36 4 */
unsigned int rsv[4]; /* 40 16 */
/* size: 56, cachelines: 1, members: 5 */
/* last cacheline: 56 bytes */
};
And now:
struct ptp_perout_request {
struct ptp_clock_time start; /* 0 16 */
struct ptp_clock_time period; /* 16 16 */
unsigned int index; /* 32 4 */
unsigned int flags; /* 36 4 */
union {
struct ptp_clock_time on; /* 40 16 */
unsigned int rsv[4]; /* 40 16 */
}; /* 40 16 */
/* size: 56, cachelines: 1, members: 5 */
/* last cacheline: 56 bytes */
};
Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2020-07-17 06:45:29 +08:00
|
|
|
#define PTP_PEROUT_ONE_SHOT (1<<0)
|
|
|
|
|
#define PTP_PEROUT_DUTY_CYCLE (1<<1)
|
ptp: introduce a phase offset in the periodic output request
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>
Signed-off-by: David S. Miller <davem@davemloft.net>
2020-07-17 06:45:30 +08:00
|
|
|
#define PTP_PEROUT_PHASE (1<<2)
|
ptp: correctly disable flags on old ioctls
Commit 415606588c61 ("PTP: introduce new versions of IOCTLs",
2019-09-13) introduced new versions of the PTP ioctls which actually
validate that the flags are acceptable values.
As part of this, it cleared the flags value using a bitwise
and+negation, in an attempt to prevent the old ioctl from accidentally
enabling new features.
This is incorrect for a couple of reasons. First, it results in
accidentally preventing previously working flags on the request ioctl.
By clearing the "valid" flags, we now no longer allow setting the
enable, rising edge, or falling edge flags.
Second, if we add new additional flags in the future, they must not be
set by the old ioctl. (Since the flag wasn't checked before, we could
potentially break userspace programs which sent garbage flag data.
The correct way to resolve this is to check for and clear all but the
originally valid flags.
Create defines indicating which flags are correctly checked and
interpreted by the original ioctls. Use these to clear any bits which
will not be correctly interpreted by the original ioctls.
In the future, new flags must be added to the VALID_FLAGS macros, but
*not* to the V1_VALID_FLAGS macros. In this way, new features may be
exposed over the v2 ioctls, but without breaking previous userspace
which happened to not clear the flags value properly. The old ioctl will
continue to behave the same way, while the new ioctl gains the benefit
of using the flags fields.
Cc: Richard Cochran <richardcochran@gmail.com>
Cc: Felipe Balbi <felipe.balbi@linux.intel.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: Christopher Hall <christopher.s.hall@intel.com>
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Acked-by: Richard Cochran <richardcochran@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-09-26 10:28:19 +08:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* flag fields valid for the new PTP_PEROUT_REQUEST2 ioctl.
|
|
|
|
|
*/
|
ptp: add ability to configure duty cycle for periodic output
There are external event timestampers (PHCs with support for
PTP_EXTTS_REQUEST) that timestamp both event edges.
When those edges are very close (such as in the case of a short pulse),
there is a chance that the collected timestamp might be of the rising,
or of the falling edge, we never know.
There are also PHCs capable of generating periodic output with a
configurable duty cycle. This is good news, because we can space the
rising and falling edge out enough in time, that the risks to overrun
the 1-entry timestamp FIFO of the extts PHC are lower (example: the
perout PHC can be configured for a period of 1 second, and an "on" time
of 0.5 seconds, resulting in a duty cycle of 50%).
A flag is introduced for signaling that an on time is present in the
perout request structure, for preserving compatibility. Logically
speaking, the duty cycle cannot exceed 100% and the PTP core checks for
this.
PHC drivers that don't support this flag emit a periodic output of an
unspecified duty cycle, same as before.
The duty cycle is encoded as an "on" time, similar to the "start" and
"period" times, and reuses the reserved space while preserving overall
binary layout.
Pahole reported before:
struct ptp_perout_request {
struct ptp_clock_time start; /* 0 16 */
struct ptp_clock_time period; /* 16 16 */
unsigned int index; /* 32 4 */
unsigned int flags; /* 36 4 */
unsigned int rsv[4]; /* 40 16 */
/* size: 56, cachelines: 1, members: 5 */
/* last cacheline: 56 bytes */
};
And now:
struct ptp_perout_request {
struct ptp_clock_time start; /* 0 16 */
struct ptp_clock_time period; /* 16 16 */
unsigned int index; /* 32 4 */
unsigned int flags; /* 36 4 */
union {
struct ptp_clock_time on; /* 40 16 */
unsigned int rsv[4]; /* 40 16 */
}; /* 40 16 */
/* size: 56, cachelines: 1, members: 5 */
/* last cacheline: 56 bytes */
};
Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2020-07-17 06:45:29 +08:00
|
|
|
#define PTP_PEROUT_VALID_FLAGS (PTP_PEROUT_ONE_SHOT | \
|
ptp: introduce a phase offset in the periodic output request
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>
Signed-off-by: David S. Miller <davem@davemloft.net>
2020-07-17 06:45:30 +08:00
|
|
|
PTP_PEROUT_DUTY_CYCLE | \
|
|
|
|
|
PTP_PEROUT_PHASE)
|
ptp: correctly disable flags on old ioctls
Commit 415606588c61 ("PTP: introduce new versions of IOCTLs",
2019-09-13) introduced new versions of the PTP ioctls which actually
validate that the flags are acceptable values.
As part of this, it cleared the flags value using a bitwise
and+negation, in an attempt to prevent the old ioctl from accidentally
enabling new features.
This is incorrect for a couple of reasons. First, it results in
accidentally preventing previously working flags on the request ioctl.
By clearing the "valid" flags, we now no longer allow setting the
enable, rising edge, or falling edge flags.
Second, if we add new additional flags in the future, they must not be
set by the old ioctl. (Since the flag wasn't checked before, we could
potentially break userspace programs which sent garbage flag data.
The correct way to resolve this is to check for and clear all but the
originally valid flags.
Create defines indicating which flags are correctly checked and
interpreted by the original ioctls. Use these to clear any bits which
will not be correctly interpreted by the original ioctls.
In the future, new flags must be added to the VALID_FLAGS macros, but
*not* to the V1_VALID_FLAGS macros. In this way, new features may be
exposed over the v2 ioctls, but without breaking previous userspace
which happened to not clear the flags value properly. The old ioctl will
continue to behave the same way, while the new ioctl gains the benefit
of using the flags fields.
Cc: Richard Cochran <richardcochran@gmail.com>
Cc: Felipe Balbi <felipe.balbi@linux.intel.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: Christopher Hall <christopher.s.hall@intel.com>
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Acked-by: Richard Cochran <richardcochran@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-09-26 10:28:19 +08:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* No flags are valid for the original PTP_PEROUT_REQUEST ioctl
|
|
|
|
|
*/
|
|
|
|
|
#define PTP_PEROUT_V1_VALID_FLAGS (0)
|
|
|
|
|
|
2011-04-22 18:03:08 +08:00
|
|
|
/*
|
|
|
|
|
* struct ptp_clock_time - represents a time value
|
|
|
|
|
*
|
|
|
|
|
* The sign of the seconds field applies to the whole value. The
|
|
|
|
|
* nanoseconds field is always unsigned. The reserved field is
|
|
|
|
|
* included for sub-nanosecond resolution, should the demand for
|
|
|
|
|
* this ever appear.
|
|
|
|
|
*
|
|
|
|
|
*/
|
|
|
|
|
struct ptp_clock_time {
|
|
|
|
|
__s64 sec; /* seconds */
|
|
|
|
|
__u32 nsec; /* nanoseconds */
|
|
|
|
|
__u32 reserved;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct ptp_clock_caps {
|
|
|
|
|
int max_adj; /* Maximum frequency adjustment in parts per billon. */
|
|
|
|
|
int n_alarm; /* Number of programmable alarms. */
|
|
|
|
|
int n_ext_ts; /* Number of external time stamp channels. */
|
|
|
|
|
int n_per_out; /* Number of programmable periodic signals. */
|
|
|
|
|
int pps; /* Whether the clock supports a PPS callback. */
|
2014-03-21 05:21:52 +08:00
|
|
|
int n_pins; /* Number of input/output pins. */
|
2016-02-22 19:15:25 +08:00
|
|
|
/* Whether the clock supports precise system-device cross timestamps */
|
|
|
|
|
int cross_timestamping;
|
2020-05-02 11:35:37 +08:00
|
|
|
/* Whether the clock supports adjust phase */
|
|
|
|
|
int adjust_phase;
|
|
|
|
|
int rsv[12]; /* Reserved for future use. */
|
2011-04-22 18:03:08 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct ptp_extts_request {
|
|
|
|
|
unsigned int index; /* Which channel to configure. */
|
|
|
|
|
unsigned int flags; /* Bit field for PTP_xxx flags. */
|
|
|
|
|
unsigned int rsv[2]; /* Reserved for future use. */
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct ptp_perout_request {
|
ptp: introduce a phase offset in the periodic output request
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>
Signed-off-by: David S. Miller <davem@davemloft.net>
2020-07-17 06:45:30 +08:00
|
|
|
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;
|
|
|
|
|
};
|
2011-04-22 18:03:08 +08:00
|
|
|
struct ptp_clock_time period; /* Desired period, zero means disable. */
|
|
|
|
|
unsigned int index; /* Which channel to configure. */
|
2019-09-11 14:16:22 +08:00
|
|
|
unsigned int flags;
|
ptp: add ability to configure duty cycle for periodic output
There are external event timestampers (PHCs with support for
PTP_EXTTS_REQUEST) that timestamp both event edges.
When those edges are very close (such as in the case of a short pulse),
there is a chance that the collected timestamp might be of the rising,
or of the falling edge, we never know.
There are also PHCs capable of generating periodic output with a
configurable duty cycle. This is good news, because we can space the
rising and falling edge out enough in time, that the risks to overrun
the 1-entry timestamp FIFO of the extts PHC are lower (example: the
perout PHC can be configured for a period of 1 second, and an "on" time
of 0.5 seconds, resulting in a duty cycle of 50%).
A flag is introduced for signaling that an on time is present in the
perout request structure, for preserving compatibility. Logically
speaking, the duty cycle cannot exceed 100% and the PTP core checks for
this.
PHC drivers that don't support this flag emit a periodic output of an
unspecified duty cycle, same as before.
The duty cycle is encoded as an "on" time, similar to the "start" and
"period" times, and reuses the reserved space while preserving overall
binary layout.
Pahole reported before:
struct ptp_perout_request {
struct ptp_clock_time start; /* 0 16 */
struct ptp_clock_time period; /* 16 16 */
unsigned int index; /* 32 4 */
unsigned int flags; /* 36 4 */
unsigned int rsv[4]; /* 40 16 */
/* size: 56, cachelines: 1, members: 5 */
/* last cacheline: 56 bytes */
};
And now:
struct ptp_perout_request {
struct ptp_clock_time start; /* 0 16 */
struct ptp_clock_time period; /* 16 16 */
unsigned int index; /* 32 4 */
unsigned int flags; /* 36 4 */
union {
struct ptp_clock_time on; /* 40 16 */
unsigned int rsv[4]; /* 40 16 */
}; /* 40 16 */
/* size: 56, cachelines: 1, members: 5 */
/* last cacheline: 56 bytes */
};
Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2020-07-17 06:45:29 +08:00
|
|
|
union {
|
|
|
|
|
/*
|
|
|
|
|
* The "on" time of the signal.
|
|
|
|
|
* Must be lower than the period.
|
|
|
|
|
* Valid only if (flags & PTP_PEROUT_DUTY_CYCLE) is set.
|
|
|
|
|
*/
|
|
|
|
|
struct ptp_clock_time on;
|
|
|
|
|
/* Reserved for future use. */
|
|
|
|
|
unsigned int rsv[4];
|
|
|
|
|
};
|
2011-04-22 18:03:08 +08:00
|
|
|
};
|
|
|
|
|
|
2012-10-31 14:19:07 +08:00
|
|
|
#define PTP_MAX_SAMPLES 25 /* Maximum allowed offset measurement samples. */
|
|
|
|
|
|
|
|
|
|
struct ptp_sys_offset {
|
|
|
|
|
unsigned int n_samples; /* Desired number of measurements. */
|
|
|
|
|
unsigned int rsv[3]; /* Reserved for future use. */
|
|
|
|
|
/*
|
|
|
|
|
* Array of interleaved system/phc time stamps. The kernel
|
|
|
|
|
* will provide 2*n_samples + 1 time stamps, with the last
|
|
|
|
|
* one as a system time stamp.
|
|
|
|
|
*/
|
|
|
|
|
struct ptp_clock_time ts[2 * PTP_MAX_SAMPLES + 1];
|
|
|
|
|
};
|
|
|
|
|
|
2018-11-09 18:14:44 +08:00
|
|
|
struct ptp_sys_offset_extended {
|
|
|
|
|
unsigned int n_samples; /* Desired number of measurements. */
|
|
|
|
|
unsigned int rsv[3]; /* Reserved for future use. */
|
|
|
|
|
/*
|
|
|
|
|
* Array of [system, phc, system] time stamps. The kernel will provide
|
|
|
|
|
* 3*n_samples time stamps.
|
|
|
|
|
*/
|
|
|
|
|
struct ptp_clock_time ts[PTP_MAX_SAMPLES][3];
|
|
|
|
|
};
|
|
|
|
|
|
2016-02-22 19:15:25 +08:00
|
|
|
struct ptp_sys_offset_precise {
|
|
|
|
|
struct ptp_clock_time device;
|
|
|
|
|
struct ptp_clock_time sys_realtime;
|
|
|
|
|
struct ptp_clock_time sys_monoraw;
|
|
|
|
|
unsigned int rsv[4]; /* Reserved for future use. */
|
|
|
|
|
};
|
|
|
|
|
|
2014-03-21 05:21:52 +08:00
|
|
|
enum ptp_pin_function {
|
|
|
|
|
PTP_PF_NONE,
|
|
|
|
|
PTP_PF_EXTTS,
|
|
|
|
|
PTP_PF_PEROUT,
|
|
|
|
|
PTP_PF_PHYSYNC,
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct ptp_pin_desc {
|
|
|
|
|
/*
|
|
|
|
|
* Hardware specific human readable pin name. This field is
|
|
|
|
|
* set by the kernel during the PTP_PIN_GETFUNC ioctl and is
|
|
|
|
|
* ignored for the PTP_PIN_SETFUNC ioctl.
|
|
|
|
|
*/
|
|
|
|
|
char name[64];
|
|
|
|
|
/*
|
|
|
|
|
* Pin index in the range of zero to ptp_clock_caps.n_pins - 1.
|
|
|
|
|
*/
|
|
|
|
|
unsigned int index;
|
|
|
|
|
/*
|
|
|
|
|
* Which of the PTP_PF_xxx functions to use on this pin.
|
|
|
|
|
*/
|
|
|
|
|
unsigned int func;
|
|
|
|
|
/*
|
|
|
|
|
* The specific channel to use for this function.
|
|
|
|
|
* This corresponds to the 'index' field of the
|
|
|
|
|
* PTP_EXTTS_REQUEST and PTP_PEROUT_REQUEST ioctls.
|
|
|
|
|
*/
|
|
|
|
|
unsigned int chan;
|
|
|
|
|
/*
|
|
|
|
|
* Reserved for future use.
|
|
|
|
|
*/
|
|
|
|
|
unsigned int rsv[5];
|
|
|
|
|
};
|
|
|
|
|
|
2011-04-22 18:03:08 +08:00
|
|
|
#define PTP_CLK_MAGIC '='
|
|
|
|
|
|
|
|
|
|
#define PTP_CLOCK_GETCAPS _IOR(PTP_CLK_MAGIC, 1, struct ptp_clock_caps)
|
|
|
|
|
#define PTP_EXTTS_REQUEST _IOW(PTP_CLK_MAGIC, 2, struct ptp_extts_request)
|
|
|
|
|
#define PTP_PEROUT_REQUEST _IOW(PTP_CLK_MAGIC, 3, struct ptp_perout_request)
|
|
|
|
|
#define PTP_ENABLE_PPS _IOW(PTP_CLK_MAGIC, 4, int)
|
2012-10-31 14:19:07 +08:00
|
|
|
#define PTP_SYS_OFFSET _IOW(PTP_CLK_MAGIC, 5, struct ptp_sys_offset)
|
2014-03-21 05:21:52 +08:00
|
|
|
#define PTP_PIN_GETFUNC _IOWR(PTP_CLK_MAGIC, 6, struct ptp_pin_desc)
|
|
|
|
|
#define PTP_PIN_SETFUNC _IOW(PTP_CLK_MAGIC, 7, struct ptp_pin_desc)
|
2016-02-22 19:15:25 +08:00
|
|
|
#define PTP_SYS_OFFSET_PRECISE \
|
|
|
|
|
_IOWR(PTP_CLK_MAGIC, 8, struct ptp_sys_offset_precise)
|
2018-11-09 18:14:44 +08:00
|
|
|
#define PTP_SYS_OFFSET_EXTENDED \
|
2019-01-07 23:22:38 +08:00
|
|
|
_IOWR(PTP_CLK_MAGIC, 9, struct ptp_sys_offset_extended)
|
2011-04-22 18:03:08 +08:00
|
|
|
|
2019-09-11 14:16:21 +08:00
|
|
|
#define PTP_CLOCK_GETCAPS2 _IOR(PTP_CLK_MAGIC, 10, struct ptp_clock_caps)
|
|
|
|
|
#define PTP_EXTTS_REQUEST2 _IOW(PTP_CLK_MAGIC, 11, struct ptp_extts_request)
|
|
|
|
|
#define PTP_PEROUT_REQUEST2 _IOW(PTP_CLK_MAGIC, 12, struct ptp_perout_request)
|
|
|
|
|
#define PTP_ENABLE_PPS2 _IOW(PTP_CLK_MAGIC, 13, int)
|
|
|
|
|
#define PTP_SYS_OFFSET2 _IOW(PTP_CLK_MAGIC, 14, struct ptp_sys_offset)
|
|
|
|
|
#define PTP_PIN_GETFUNC2 _IOWR(PTP_CLK_MAGIC, 15, struct ptp_pin_desc)
|
|
|
|
|
#define PTP_PIN_SETFUNC2 _IOW(PTP_CLK_MAGIC, 16, struct ptp_pin_desc)
|
|
|
|
|
#define PTP_SYS_OFFSET_PRECISE2 \
|
|
|
|
|
_IOWR(PTP_CLK_MAGIC, 17, struct ptp_sys_offset_precise)
|
|
|
|
|
#define PTP_SYS_OFFSET_EXTENDED2 \
|
|
|
|
|
_IOWR(PTP_CLK_MAGIC, 18, struct ptp_sys_offset_extended)
|
|
|
|
|
|
2011-04-22 18:03:08 +08:00
|
|
|
struct ptp_extts_event {
|
|
|
|
|
struct ptp_clock_time t; /* Time event occured. */
|
|
|
|
|
unsigned int index; /* Which channel produced the event. */
|
|
|
|
|
unsigned int flags; /* Reserved for future use. */
|
|
|
|
|
unsigned int rsv[2]; /* Reserved for future use. */
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
#endif
|
