> 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/