On Jan 17,  1:23pm, Brad Walker wrote:
} Subject: Re: Serial port issues on Sun4/260
} > Date: Wed, 17 Jan 1996 13:32:54 -0500
} > From: der Mouse <mouse@Collatz.McRCIM.McGill.EDU>
} > To: port-sparc@netbsd.org
} > Subject: Re: Serial port issues on Sun4/260
} > Cc: bwalker@musings.com
} > 
} > >> [T]he zs chip will never wiggle any signal to get the modem to shut
} > >> up.  This means you must never overflow the zs chip's fifo.

Even if it had the capability, it's FIFO is too small.  You need at least
a few characters of buffering beyond the point at which to tell the
sender to shut up in order to give the sender time to receive the signal
and stop sending, plus you have to absorb any characters that are already
in flight.  Actually, it looks like quite a bit of slack is needed, since
it appears to me that a '550 UART doesn't have HW flow control built in.
It looks like all the modem control signals have to be handled by its host,
so if the sender is a '550 with a full transmit FIFO, we'll have to be
prepared to absorb the whole mess.

} > > This is a great reason for implementation of STREAMS..
} > 
} > How can STREAMS help any?  No software can give the hardware
} > capabilities it doesn't have.
} > 
} 
} I'm not suggesting that streams (ie. i do this in lower case to make
} the typing easier) give the hardware more that it's capable of. What
} I'm suggesting is that streams gives the system the ability to better
} buffer events (ie. async events) that happen when the system is not
} really able to handle things.

The pre-STREAMS SunOS zs driver outperforms the STREAMS version in SunOS
4.x.  As I recall, an old Sun 3 with the old driver could keep up with
38400, but it takes a pretty healthy Sun 4 to do that with STREAMS driver.

} For example, if your application has a serial port open and data is
} coming in but the read system call hasn't been called from the
} application, the driver is still going to call the receive intr.
} routine.  If you have data flowing in a high baud rate then you need to
} place it somewhere.

The current implementation shoves the data into a ring buffer.  I
don't see any reason that the receive interrupt code couldn't tell
the zs chip to wiggle a signal to squelch the sender if the ring
buffer started getting full in HW flow control mode.  XON/XOFF is
another story, but who depends on that at high speeds?  BTW, it
looks like the ring buffer could also fill if status change events
roll in at high speed.  Consecutive events should probably be
collapsed if they are close enough together.