Messages in this thread | | | Subject | Re: TTY_FLIPBUF_SIZE too low causing dataloss on too fast serial lines? | From | Dag Brattli <> | Date | 01 Jun 1999 12:44:26 +0100 |
| |
David Woodhouse <David.Woodhouse@mvhi.com> writes:
> The Infra-Red people have worked round this by providing dedicated drivers for > driving a 16550 synchronously. I don't really think that's a good idea, > and I was quite glad to see the N_HDLC synchronous-tty support which arrived > circa 2.2.5. > > If we make the normal serial driver support this synchronous-tty mode, then it > can be used for IR support, and also fieldbus support, and the duplicate > drivers can be dropped.
Think, I need to explain this a little bit. The reason why we are moving away from irtty (the IrDA line discipline) and want to use irport (simple serial driver), is mainly because it's hard to make the Linux serial driver work in half-duplex only mode. This is required if the IrDA hardware does not do any echo-cancelling of what it's transmitting itself. I actually have a dongle where I receive _all_ frames that I transmit myself when using irtty (and the Linux serial driver). Almost all IrDA hardware I have seen uses a 16550 compatible UART for SIR speeds (9600-115200 bps), and the ones who don't is not supported by the Linux serial driver either.
Irport is async and tries to work in half-duplex only mode, and turns off receive interrupts while transmitting, and flushes the Rx FIFO when finished transmitting to make sure no data has been reflected back.
But yes, using irport removes the SERIAL_BH from the data-path. When using IrLAN and irtty, we actually goes through 3 BH's: SERIAL_BH (serial data) -> NET_BH (irda frames) -> NET_BH (ethernet frames). So irport has much better performance (latency/throughput) than when using irtty!
So we are not doing this to drive an 16550 synchronously! Synchronous IrDA called MIR (576000 and 1152000 bps) is always implemented entirely by the IrDA controller chip, so the driver will look more like a network device driver than a serial driver (and that is the reason I made the decision to implement them as network device drivers). MIR is actually not much used anymore because most chips that supports these speeds also supports FIR mode (4Mbps). FIR mode does not use HDLC wrapping or stuffing, but a mode called 4PPM which is very different (no need for stuffing at all). VFIR (16Mbps) does not use HDLC wrap or stuff either.
So IrDA SIR mode uses async mode which and has to be framed and stuffed in software. MIR and FIR mode are however handled in hardware, and those chips has very frame oriented interfaces. So we don't really need any special HDLC TTY handling. In my view IrDA device drivers are network device drivers, irtty is actually a line discipline in bottom and a network device driver at the top. Irport and the rest of the special device drivers we have work as network device drivers only. Most IrDA chips out there are very different so most of them need dedicated drivers.
Irtty will however always be around for those who want/needs to use it. If somebody wants to run IrDA over a sync serial line, then it should be easy to make irtty handle that case as well. But they whould have to put a little effort self tho'
-- Dag
-- / Dag Brattli | The Linux-IrDA Project / // University of Tromsoe, Norway | Infrared communication for Linux // /// http://www.cs.uit.no/~dagb | http://www.cs.uit.no/linux-irda/ ///
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |