xiaomi-sm8450/android_kernel_xiaomi_sm8450
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

drivers/pps: aesthetic tweaks to PPS-related content

Browse Source 
Collection of aesthetic adjustments to various PPS-related files,
directories and Documentation, some quite minor just for the sake of
consistency, including:

 * Updated example of pps device tree node (courtesy Rodolfo G.)
 * "PPS-API" -> "PPS API"
 * "pps_source_info_s" -> "pps_source_info"
 * "ktimer driver" -> "pps-ktimer driver"
 * "ppstest /dev/pps0" -> "ppstest /dev/pps1" to match example
 * Add missing PPS-related entries to MAINTAINERS file
 * Other trivialities

Link: http://lkml.kernel.org/r/alpine.LFD.2.20.1708261048220.8106@localhost.localdomain
Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>
Acked-by: Rodolfo Giometti <giometti@enneenne.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This commit is contained in:
Robert P. J. Day
2017-09-08 16:17:19 -07:00
committed by Linus Torvalds
parent f22ef333c3
commit a2d8180301
7 changed files with 43 additions and 36 deletions
Download Patch File Download Diff File Expand all files Collapse all files

44
Documentation/pps/pps.txt
View File

@@ -48,12 +48,12 @@ problem:
time_pps_create().
This implies that the source has a /dev/... entry. This assumption is
ok for the serial and parallel port, where you can do something
OK for the serial and parallel port, where you can do something
useful besides(!) the gathering of timestamps as it is the central
task for a PPS-API. But this assumption does not work for a single
task for a PPS API. But this assumption does not work for a single
purpose GPIO line. In this case even basic file-related functionality
(like read() and write()) makes no sense at all and should not be a
precondition for the use of a PPS-API.
precondition for the use of a PPS API.
The problem can be simply solved if you consider that a PPS source is
not always connected with a GPS data source.
@@ -88,13 +88,13 @@ Coding example
--------------
To register a PPS source into the kernel you should define a struct
pps_source_info_s as follows:
pps_source_info as follows:
static struct pps_source_info pps_ktimer_info = {
.name = "ktimer",
.path = "",
.mode = PPS_CAPTUREASSERT | PPS_OFFSETASSERT | \
PPS_ECHOASSERT | \
.mode = PPS_CAPTUREASSERT | PPS_OFFSETASSERT |
PPS_ECHOASSERT |
PPS_CANWAIT | PPS_TSFMT_TSPEC,
.echo = pps_ktimer_echo,
.owner = THIS_MODULE,
@@ -108,13 +108,13 @@ initialization routine as follows:
The pps_register_source() prototype is:
int pps_register_source(struct pps_source_info_s *info, int default_params)
int pps_register_source(struct pps_source_info *info, int default_params)
where "info" is a pointer to a structure that describes a particular
PPS source, "default_params" tells the system what the initial default
parameters for the device should be (it is obvious that these parameters
must be a subset of ones defined in the struct
pps_source_info_s which describe the capabilities of the driver).
pps_source_info which describe the capabilities of the driver).
Once you have registered a new PPS source into the system you can
signal an assert event (for example in the interrupt handler routine)
@@ -142,8 +142,10 @@ If the SYSFS filesystem is enabled in the kernel it provides a new class:
Every directory is the ID of a PPS sources defined in the system and
inside you find several files:
$ ls /sys/class/pps/pps0/
assert clear echo mode name path subsystem@ uevent
$ ls -F /sys/class/pps/pps0/
assert dev mode path subsystem@
clear echo name power/ uevent
Inside each "assert" and "clear" file you can find the timestamp and a
sequence number:
@@ -154,32 +156,32 @@ sequence number:
Where before the "#" is the timestamp in seconds; after it is the
sequence number. Other files are:
* echo: reports if the PPS source has an echo function or not;
* echo: reports if the PPS source has an echo function or not;
* mode: reports available PPS functioning modes;
* mode: reports available PPS functioning modes;
* name: reports the PPS source's name;
* name: reports the PPS source's name;
* path: reports the PPS source's device path, that is the device the
PPS source is connected to (if it exists).
* path: reports the PPS source's device path, that is the device the
PPS source is connected to (if it exists).
Testing the PPS support
-----------------------
In order to test the PPS support even without specific hardware you can use
the ktimer driver (see the client subsection in the PPS configuration menu)
the pps-ktimer driver (see the client subsection in the PPS configuration menu)
and the userland tools available in your distribution's pps-tools package,
http://linuxpps.org , or https://github.com/ago/pps-tools .
http://linuxpps.org , or https://github.com/redlab-i/pps-tools.
Once you have enabled the compilation of ktimer just modprobe it (if
Once you have enabled the compilation of pps-ktimer just modprobe it (if
not statically compiled):
# modprobe ktimer
# modprobe pps-ktimer
and the run ppstest as follow:
$ ./ppstest /dev/pps0
$ ./ppstest /dev/pps1
trying PPS source "/dev/pps1"
found PPS source "/dev/pps1"
ok, found 1 source(s), now start fetching data...
@@ -187,7 +189,7 @@ and the run ppstest as follow:
source 0 - assert 1186592700.388931295, sequence: 365 - clear 0.000000000, sequence: 0
source 0 - assert 1186592701.389032765, sequence: 366 - clear 0.000000000, sequence: 0
Please, note that to compile userland programs you need the file timepps.h .
Please note that to compile userland programs, you need the file timepps.h.
This is available in the pps-tools repository mentioned above.