lkml.org 
[lkml]   [2007]   [Mar]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 1/1] LinuxPPS: Pulse per Second support for Linux
On Wed, Mar 14, 2007 at 09:19:34AM -0400, Lennart Sorensen wrote:
>
> I will grab the last couple of commits and try although they didn't
> sound like they really make much difference.

Some fixes up... see the git log for further info.

> I couldn't find any way to do that with setserial (at least not the
> version I have), and I would rather not have to install setserial just
> to do that. Which version of setserial is needed and what arguments
> does it need to do it?

Unluckely you need a patched version of setserial (see the patch on my
site). On the same site you can find a precompiled version which I use
for my tests, maybe it works for you...

> If it is NOT connected to the same device, then how would you specify
> it? The ntp configuration is rather sparse when it comes to specifying
> anything and seems to rely in symlinks to hardcoded device names for
> finding everything. I suppose one could have gps# for the nmea messages
> and pps# for the associated pps device name symlink (which may point
> to something that doesn't even exist if there is an internal source of
> that name with no associated device). Does that seem reasonable? I can
> certainly change it to do that. Certainly refclock_atom already uses
> /dev/pps# as it's device, so using that again may be reasonable.

This is a specific problem of NTPD not of LinuxPPS itself. I wrote
some letters about this problem into NTP list but with no results.

The sysadm shoulkd use setserial to enable a serial port to become a
PPS source and then NTPD should verify if such PPS source exists
(using time_pps_findpath() & Co.).

> I actually find the way it determines the pps device a bit annoying.
> Right now I have to do this:
>
> cd /dev
> ln -s ttyn0 jsm0
> ln -s jsm0 gps0
>
> This way gps0 is the symlink the ntp refclock looks for when asked for
> device 0, and readlink turns that into jsm0 (since the internal driver
> name for ttyn0 is jsm, that is what the pps code insists it must be
> named), which then is another symlink to the real device name. Same for
> ttyS3 <- serial3 <- gps0. Now it would be nice if the internal driver
> name matched the device name, but apparently that really never seems to
> happen. Is all this symlink spagheti really necesary?

Did you read this example on the wiki?

giometti@jeeg:~/linuxpps$ cat /sys/class/pps/01/name
serial1
giometti@jeeg:~/linuxpps$ cat /sys/class/pps/01/path
/dev/ttyS1
giometti at jeeg:~/linuxpps/test$ sudo ln -sf /dev/ttyS1 /dev/gps0
giometti at jeeg:~/linuxpps/test$ sudo ./ppstest /dev/gps0
found PPS source #2 "serial1" on "/dev/ttyS1"
giometti at jeeg:~/linuxpps/test$ sudo ln -sf ktimer /dev/gps0
giometti at jeeg:~/linuxpps/test$ sudo ./ppstest /dev/gps0
found PPS source #0 "ktimer" on ""

it doesn't work for you?

> Will do.

Thanks a lot,

Rodolfo

--

GNU/Linux Solutions e-mail: giometti@enneenne.com
Linux Device Driver giometti@gnudd.com
Embedded Systems giometti@linux.it
UNIX programming phone: +39 349 2432127
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2007-03-14 15:09    [W:0.343 / U:0.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site