Message-ID: <20070314140623.GF3802@enneenne.com>
Date:	Wed, 14 Mar 2007 15:06:23 +0100
From:	Rodolfo Giometti <giometti@...eenne.com>
To:	Lennart Sorensen <lsorense@...lub.uwaterloo.ca>
Cc:	linux-kernel@...r.kernel.org, linuxpps@...enneenne.com,
	Russell King <rmk+lkml@....linux.org.uk>,
	Jan Dittmer <jdi@....org>, Pavel Machek <pavel@....cz>
Subject: Re: [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@...g:~/linuxpps$ cat /sys/class/pps/01/name
   serial1 
   giometti@...g:~/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@...eenne.com
Linux Device Driver                             giometti@...dd.com
Embedded Systems                     		giometti@...ux.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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists