Subject: Re: DS5240 serial ports
To: Bill Studenmund <skippy@macro.Stanford.EDU>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
List: port-pmax
Date: 05/11/1999 15:59:53
>Jonathan, you'll get one interrupt per character. Though there is a 3-byte
>fifo, each receive generates an interrupt. So you'll be getting ~ 5800
>interrupts/sec, and you have to service them within 519 ms (how long it
>takes to overflow the fifo at 57600).

So you only have to service them at aroud 2Khz.  I dunno, I've only
ever tested high speed talking to a Richochet at 115200.  That works
fine, doesnt drop chars, and I can do other work. But the duty cycle
is at most ten 1200-byte packets/sec.

>I think the real problem is that the current scc driver doesn't use a
>silo like the MI driver does. Thus anything in the kernel at spltty (or
>splimp) blocks tty char reception. For the MI driver, spltty & splimp only
>block the processing of characters, not their reception.


>> Better pdma would be nice, but so would output DMA...
>
>I haven't forgotten that Jason and I want to fix up the alpha version of
>the driver, which will probably fix the pmax one too. ;-)


Yeah. Since you mention it, its a bit unpleasant the way the
copyrights on that driver get nuked wiht the Alpha one, as if CMU and
CGD were the only source of what went into it.  There were changes
from 4.4-lite, and I spent a lot of time working on those and merging
the Alpha and pmax drivers. whatever...


>I doubt it's Zilog vs. AMD or clock divider (if you were still running the
>BRG and the channel in /16 mode). mac68k uses AMD chips in some machines,
>and Zilog cores in others. All have been able to run at 57600 baud, which
>uses the same divider constant (0) as 115200 on pmax.

I dunno.  This was the same machine where i still had to put in the
DELAY() macros for 1.6 usec onchip settle time.  Someone told me quite
rudely that the DELAY()s weren't necessary because the problem was
"fixed in hardware".  Maybe on Alphas it is, but not on the first
5000/240 I brought up.


>I thought you were playing with /1 mode at one point? THAT will definitely
>cause problems. :-)

I was, but I'm pretty sure this was with 16-sample mode with the
divisor set to 0. I think 78.6 didnt work on this particular machine
eihter.

IIRC we'd have to go to 1-sample mode to go to 230k, but that's synch
anyway. Or does localtalk provide an external clock?