From owner-freebsd-hackers Wed Nov 12 23:43:29 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA25378 for hackers-outgoing; Wed, 12 Nov 1997 23:43:29 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA25370 for ; Wed, 12 Nov 1997 23:43:24 -0800 (PST) (envelope-from bde@zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.6.9) id SAA02104; Thu, 13 Nov 1997 18:37:56 +1100 Date: Thu, 13 Nov 1997 18:37:56 +1100 From: Bruce Evans Message-Id: <199711130737.SAA02104@godzilla.zeta.org.au> To: bde@zeta.org.au, mouth@ibm.net Subject: Re: Status of 650 UART support Cc: hackers@freebsd.org Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >>>Did you know that the 650 UART has on-chip "auto" RTS flow control > >>On some (early? all?) 16650s it is said to be just a pessimization >>to use it, since it is invoked when the trigger level is reached, >>so it is invoked for almost every input interrupt. > >It may seem like a pessimization if your ISR always starts quickly >enough to avoid UART overruns. However, when using a 550 UART, My ISRs always do :-). >presumably the serial ISR could safely raise RTS as its first duty >when the FIFO trigger level has been reached, since the external >device would be expected to have a large buffer of its own. If true, >then why not have the 650 chip raise RTS automatically? That buys It is unkind to the external device. It would approximately triple the number of interrupts for a similar device that is only sending. E.g., for a sender that sends 32 bytes at a time, and a receiver with a trigger level of 28, there would be about two useless modem status change interrupts in the sender for every 32 bytes sent. >Does the sio.c ISR raise RTS when servicing a UART trigger level >interrupt, or does it simply drain the UART FIFO while letting the >external device keep streaming inbound bytes? If the latter is true, >>I don't know what happens when the driver sets RTS directly. > >The Startech databook says: > >> 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. >> RTS pin resumes it original state after content of the >> data buffer (FIFO) drops below the next lower trigger level. >> ... hardware ... flow controls can be enabled for automatic >> operation. During these conditions the ST16C650 will accept >> additional data to fill the unused ... recieve FIFO locations. This is OK. >2) Receive (not transmit) FIFO trigger levels, 550 vs. 650: > >=46CR bit 7 and 6 550 650 > 00 1 8 > 01 4 16 > 10 8 24 > 11 14 28 > >If the software driver sets FCR to "10" as you would expect in the >case of a 550 UART, the 650 trigger level will actually be 24 and the >next lower trigger level will be 16. The excerpt from the databook 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 think the best available setup is to use 16550 mode with the tx fifo >>size set to match the flow control. The 16650 configuration is too >>specific - it forces 16650 flow control and a 32 byte tx fifo size. > >I don't follow you here. FCR bits 5 and 4 on the 650 allow setting >the transmit FIFO to 16, 8, 24, or 30. The default is 16. However, >none of these are in effect unless, as the databook says: > >> ... user can write to transmit trigger levels but activation will not >> take place till ST16C650 special mode is selected (EFR bit-4 >> is set to "1"). > >> ... to be compatible with ... 550, 1 bytes transmit trigger level is >> selected after reset. > >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. Bruce