Subject: Re: com.c patch to track PPS
To: Bill Studenmund <firstname.lastname@example.org>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
Date: 02/07/2000 10:54:48
In message <Pine.SOL.3.96.1000207102332.11519Bemail@example.com>Bill S
>"low" and "high" are confusing in RS-232. Since a "1" is a voltage lower
>than -3 V, and a "0" is one over +3, "active low" is rather ambiguous.
Yep. That's why the PPS-API uses "assert" and "clear". The I-D was
trying to avoid that ambiguity. Guess it didn't work so well.
>I think what the chips do is that a "1" in the status register means
Thats what I found by carefully removing and re-inserting the serial
cable to a ricochet.
>> But yep, thats one reason I left the sc_msr_mask alone. The other is
>> that I think the com driver takes interrupts for DCD changes even if
>> MSR_DCD is off in sc_msr_mask.
>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.
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?