Subject: Re: fifo overrun
To: None <port-sparc@NetBSD.ORG>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
List: port-sparc
Date: 05/12/1998 09:10:22
> Date: Wed, 29 Oct 1997 09:34:33 -0500 (EST)

This is old, but I don't recall seeing any response.

> I got to testing the fifo overrun problem a little, and there is no
> problem at 19.2, but there is at 38400.  I'd like to try values in
> between, but tcsetattr won't permit them.  Is there a reason why it
> has to be this way?  Seems like 28.8 and 33.whatever should be
> allowed too.

Yes, there is a reason: only values that are divisors of the clock
frequency driving the UART are possible.  The driver knows this clock
frequency (it has to, in order to compute the correct values for the
divisor registers) and won't permit values that can't be achieved.

IIRC, there is one note: the real clock frequency is divided by 16
before being fed to the divisor chain.  This is semi-necessary to get
reasonably accurate sampling of received characters; without that, it's
hard to make sure you sample the incoming bits approximately at the
middle of their bit times.  (Doing this makes character reception more
resistant to slight baud-rate mismatches.)

If you're feeling ambitious, you could hack the driver to switch from
divide-by-16 to divide-by-1 when userland tries to set a baudrate that
is impossible with the former but achievable with the latter.  I've
never tried this myself, but there's no theoretical reason it shouldn't
be workable.  Of course, when using divide-by-1, the potentially
borderline sampling means your error rate is bound to rise.

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B