Re: Hardware interrupt list?

[Ken Hornstein <kenh%pobox.com@localhost>]

>It all boils down to this:  If and only if the kernel PPS code is 
>activated by ntpd FIRST, before anything tries to open the serial port 
>to actually read data, I am then able to start up gpsd (and by extension 
>the GPS reference clock) and have both GPS and PPS working simultaneously.
>
>However, if the serial port is captured by gpsd (and by extension the 
>GPS reference clock) FIRST, before the kernel PPS is activated, kernel 
>PPS fails and I get no PPS ticks.

Okay, I have an idea.

From the zs8530 driver, it looks like you need to specifically set up
the serial chip to get interrupts for DCD changes (which is what you
care about).  This is handled by zs_maskintr(), and if you look at
the zs_maskintr() code you'll see it specifically checks to see if you
want interrupts for changes in DCD.

Now zs_maskintr() is called in two places: by zsparam() and by the ioctl
code that handles TIOCDCDTIMESTAMP, the _old_ API.  But the code that
handles the _new_ PPS API calls (PPS_IOC_*) doesn't call zs_maskintr().

I suspect that what's happening is when you open the device first and set
up the PPS API stuff, the upper layer TTY code calls down to zsparam()
and ends up setting the interrupt mask correctly.  But if you open it
_second_, then the tty layer has already configured the device and zsparam()
never gets called (and thus zs_maskintr()) never gets called again).

So maybe if you put a call in to zs_maskintr() in the PPS handling code
in zsioctl(), that will solve your problem?  Should be an easy change to
test out.

--Ken