On Mon, 7 Feb 2000, Jonathan Stone wrote:

> In message <Pine.SOL.3.96.1000207102332.11519B-100000@marcy.nas.nasa.gov>Bill S
> tudenmund writes
> 
> >Then that's a difference between the drivers. The zs driver only asserts
> >interrupts for the bits set in cs_rr0_mask.
> 
> OK.  My guess is that DCD is unlikley to waggle often enough to
> cause a significant interupt load -- certainly not for PPS --
> but maybe its worth looking into.

Bad guess for mac's (ppc and 68k). Apple feeds clock sources on the DCD
and the CTS signal lines, and we DON'T want to enable interrupts if they
are there. :-)

> BTW, the sys/dev/ic/com.c code in today's sup worked for me, both when
> the line discipline set CLOCAL (via tip) and when it didn't, so it
> should work with a real PPS clock.
> 
> 
> Hm.  How should we handle someone trying to enable PPS on a line with
> MDMBUF set, or vice-versa?  Return an error, but EBUSY, or EINVAL?

The zs code I added returns EINVAL. The md code sets cs_rr0_pps, which is
the bit in rr0 (the status byte) which can be used for pps (DCD only right
now). If it's 0 when you do a PPS_IOC_SETPARAMS, we return EINVAL. If
we're in MDMBUF or CDTRCTS, we don't set this bit.

Take care,

Bill