[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: serial port forever

On Sun, 7 Oct 2001 johana@xxxxxxx.com wrote:
> You might want to take a look in the elinux version
> (elinux/drivers/char/etrax100ser.c)
> where we set the d_wait bit in the DMA descriptor when setting up the
> transmit
> so that the interrupt comes after the FIFO is empty - we then only have to

But note that this is not the best solution because you don't want to
minimize the required latency between the IRQ and the next start of a
buffer. What's the point of having a FIFO at all if you can't pipeline a
transmission ?

The correct solution is to not close the port if there is still data that
has to be sent (obviously).

> An easier way to fix the closing might be to simply comment out the row
> info->port[REG_TR_CTRL] = (info->tx_ctrl &= ~0x40);
> in shutdown() in os/linux/arch/cris/drivers/serial.c
> so we don't really disable the port even though we are closing it.
> (Don't know if this will have some nasty side effects though)

That definitely removes the cutting of of the data and in fact we ran like
that for the first versions of the serial driver (until someone
"fixed" it - was it me ? :)

I don't know if the TTY "API" actually says anything on whether the last
byte of data really has to have left the actual hardware port before the
close() returns. I don't think so. So since you're not guaranteed to being
able to close-off any data already in the pipeline, it's probably ok to
not close it off at all, and simply not send more data to the DMA.

One possibly weird side-effect could be if you have hardware flow control
enabled on the transmission, and you close() while it's blocked, you might
be surprised to see chars coming out there when the receiver enables the
reception after 5 minutes.. but you cannot have the cake and eat it too