Date: Thu, 13 Nov 1997 19:17:49 GMT From: mouth@ibm.net (John Kelly) To: Bruce Evans <bde@zeta.org.au> Cc: hackers@freebsd.org Subject: Re: Status of 650 UART support Message-ID: <346e5246.10042871@smtp-gw01.ny.us.ibm.net> In-Reply-To: <199711130737.SAA02104@godzilla.zeta.org.au> References: <199711130737.SAA02104@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 13 Nov 1997 18:37:56 +1100, Bruce Evans <bde@zeta.org.au> wrote: >>> RTS pin will be forced to high state regardless of its original >>> state when receive FIFO reaches to the programmed trigger level. > >So the pessimization is standard on Startechs :-(. The RTS trigger >level should be slightly higher than the FIFO trigger level. Not standard. It's only activated if you set EFR bit 6 to 1, which sio.c apparently does for a 650. >>=46CR bit 7 and 6 550 650 >> 00 1 8 >> 01 4 16 >> 10 8 24 >> 11 14 28 >sio actually uses 11. This gives a useful reduction of input inputs >vs. 10 and doesn't cause slo overflows for normal setups with <= 4 ports >and no (broken) bus-hogging DMA controllers. I have a near worst case scenario. I have an interrupt-sharing multiport serial adapter with eight 650s all sharing one interrupt. The clock for each UART can be individually set (via hardware jumper) to 1.8432MHz, 3.6864MHz, or 7.3728MHz, for a maximum port speed of 115.2k, 230.4k, or 460.8k. I seem to recall from sio.c that in the case of a multiport serial adapter, the ISR itself will look at every port and try to drain it. Since reducing input interrupts is a worthy goal, why not enable auto RTS and simply run the 650 receive FIFO in polled mode? You could start up in normal interrupt driven mode and jump to polled mode when data starts streaming in. With the auto RTS feature activated, the 650 will suspend the inbound data stream from the external device when necessary to prevent UART overruns, as the external device would be expected to have a large (2k? 4k?) buffer of its own to accumulate inbound data until the 650 gives it the green light again. In the case of a multiport serial adapter, each port could have a flag in sio.c which tells whether it's working in polled mode or interrupt mode. Whenever you poll the ports which are streaming data in, you would only have to check the ones which have their polling flag on, because any of the other ports not being polled would still get your attention by means of an interrupt. With a multiport serial adapter, that would eliminate some of the present overhead in the ISR where you have to check each port for inbound data every time the ISR runs. The ISR would still have to check each port which does not have its polling flag on, but as port usage increases, that ISR overhead would decrease. >>So if you don't set EFR bit 4, the 650 transmit FIFO is still only one >>byte just like a 550. And I don't recall seeing any code in sio.c to >>set EFR bit 4. > >It only sets the software tx_fifo_size to 32. This is apparently the >default if the fifos are enabled in the 16550 way. This is 16550- >compatible because the space in the fifo is not readable so 16550 >drivers would only ever put 16 bytes in the fifo. After rereading my statement above it appears misleading. It should say the 650 transmit FIFO "interrupt trigger level" is one byte after reset, but the actual FIFO capacity is nevertheless 32 bytes. The databook says the 650 "will issue a transmit empty interrupt when number of characters in FIFO drops *below* selected trigger level" So with FIFOs enabled and a default transmit trigger level of 1 (after reset) the transmitter interrupt will be issued when the FIFO drops *below* 1, not to 1. That would make the transmit interrupt function emulate the 550 which issues the interrupt when the transmit FIFO is empty, at least by default. I was somewhat confused by the *below* 1 wording before. John
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?346e5246.10042871>