Re: TTY_FLIPBUF_SIZE too low causing dataloss on too fast serial lines?

Theodore Y. Ts'o (tytso@MIT.EDU)
Fri, 28 May 1999 17:25:04 -0400 (EDT)


Date: Fri, 28 May 1999 19:49:30 +0200 (MET DST)
From: Bjorn Wesen <bjorn@sparta.lu.se>

The one exception is embedded systems (to which Linux is beginning to
catch on).

In our HW, we have 6.25 Mbaud serial ports. They can be used to talk to
other stuff on the board, or with other similar CPU's. They can also talk
with the lower standard speeds, like 1.8 Mbaud and below.

Sure, I never said they were competely useless. It's just that up until
recently, when I didn't have a lot of time to work on everything that
needed working on, fixing this wasn't high on my priority list since I
didn't see a lot of practical need for it in the immediate future.

Granted that for some embedded systems you don't want to bother with
ethernet, IP, or TCP, but even that will change over time. You can
already get a video camera which is the shape of a tennis ball which
sends its video via ethernet. It's not *that* hard to make a device be
network aware these days.

So in our Linux driver, I'm using the serial port DMA to send incoming
data into a static buffer which is, when the DMA is finished, copied into
the flip buffer and the flip call is made. On the sending side, DMA is
started directly from the xbuf.

Now, I know this is a waste of buffers and copyings and power, but it
works for now. However maybe I can optimize it by starting DMA directly
into the flipbuf or bypass the flipbuf - mayby you have a hint (I'll check
that Rocketport driver btw).

Yes, you should call the line discpline directly instead of going
through the flip buffer if that's what you're doing. See the Rocketport
driver for the details, but the short version is you call
tty->ldisc.receive_buf() directly.

- Ted

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