Date: Thu, 21 Jan 2016 00:38:39 +0100 From: Marius Strobl <marius@alchemy.franken.de> To: Ian Lepore <ian@freebsd.org> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r294362 - in head/sys: dev/uart kern sys Message-ID: <20160120233839.GN15359@alchemy.franken.de> In-Reply-To: <1453256671.46848.98.camel@freebsd.org> References: <201601192334.u0JNYST5080954@repo.freebsd.org> <1453256671.46848.98.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jan 19, 2016 at 07:24:31PM -0700, Ian Lepore wrote: > On Tue, 2016-01-19 at 23:34 +0000, Marius Strobl wrote: > > Author: marius > > Date: Tue Jan 19 23:34:27 2016 > > New Revision: 294362 > > URL: https://svnweb.freebsd.org/changeset/base/294362 > > > > Log: > > Fix tty_drain() and, thus, TIOCDRAIN of the current tty(4) incarnation > > to actually wait until the TX FIFOs of UARTs have be drained before > > returning. This is done by bringing the equivalent of the TS_BUSY flag > > found in the previous implementation back in an ABI-preserving way. > > Reported and tested by: Patrick Powell > > > > Most likely, drivers for USB-serial-adapters likewise incorporating > > TX FIFOs as well as other terminal devices that buffer output in some > > form should also provide implementations of tsw_busy. > > > > MFC after:> > 3 days > > > > Modified: > > head/sys/dev/uart/uart_tty.c > > head/sys/kern/tty.c > > head/sys/sys/ttydevsw.h > > This rocks. > > It would rock even more if uart's sc_txbusy actually meant what its > name implies, but for some hardware what it really indicates is "the > hardware can/cannot accept more data" which is not the same as "all > data has been transmitted." Even for hardware that doesn't signal > txidle until the fifo is completely empty (not just at a lowater mark), > there may still be a last byte on the way out from a tx holding > register. > Yes, I'm aware that at least for uart_dev_ns8250.c, sc_txbusy doesn't cover a character still being in the TX shift register so far. I've started working on that but it turned out to be non-trivial to get right. Marius
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160120233839.GN15359>