Date: Tue, 19 Jan 2016 19:24:31 -0700 From: Ian Lepore <ian@freebsd.org> To: Marius Strobl <marius@FreeBSD.org>, 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: <1453256671.46848.98.camel@freebsd.org> In-Reply-To: <201601192334.u0JNYST5080954@repo.freebsd.org> References: <201601192334.u0JNYST5080954@repo.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1453256671.46848.98.camel>