Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752685AbbEJKhH (ORCPT ); Sun, 10 May 2015 06:37:07 -0400 Received: from unicorn.mansr.com ([81.2.72.234]:42649 "EHLO unicorn.mansr.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752323AbbEJKhD convert rfc822-to-8bit (ORCPT ); Sun, 10 May 2015 06:37:03 -0400 X-Greylist: delayed 474 seconds by postgrey-1.27 at vger.kernel.org; Sun, 10 May 2015 06:37:02 EDT From: =?iso-8859-1?Q?M=E5ns_Rullg=E5rd?= To: Mason Cc: One Thousand Gnomes , linux-serial@vger.kernel.org, LKML , Peter Hurley Subject: Re: Hardware spec prevents optimal performance in device driver References: <554DDFF3.5060906@free.fr> <20150509183254.18b786f9@lxorguk.ukuu.org.uk> <554E72B9.8010809@free.fr> Date: Sun, 10 May 2015 11:29:03 +0100 In-Reply-To: <554E72B9.8010809@free.fr> (Mason's message of "Sat, 09 May 2015 22:48:57 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1854 Lines: 48 Mason writes: > One Thousand Gnomes wrote: > >> Mason wrote: >> >>> I'm writing a device driver for a serial-ish kind of device. >>> I'm interested in the TX side of the problem. (I'm working on >>> an ARM Cortex A9 system by the way.) >>> >>> There's a 16-byte TX FIFO. Data is queued to the FIFO by writing >>> {1,2,4} bytes to a TX{8,16,32} memory-mapped register. >>> Reading the TX_DEPTH register returns the current queue depth. >>> >>> The TX_READY IRQ is asserted when (and only when) TX_DEPTH >>> transitions from 1 to 0. >> >> If the last statement is correct then your performance is probably always >> going to suck unless there is additional invisible queueing beyond the >> visible FIFO. > > Do you agree with my assessment that the current semantics for > TX_READY lead to a race condition, unless we limit ourselves > to a single (atomic) write between interrupts? No. To get best throughput, you can simply busy-wait until TX_DEPTH indicates the FIFO is almost empty, then write a few words, but no more than you know fit in the FIFO. Repeat until all data has been written. Use the IRQ only to signal completion of the entire packet. If the transmit rate is low, you can save some CPU time by filling the FIFO, then sleeping until it should be almost empty, fill again, etc. Whether busy-waiting or sleeping, this approach keeps the data flowing as fast as possible. With the hardware you describe, there is unfortunately a trade-off between throughput and CPU efficiency. You'll have to decide which is more important to you. -- M?ns Rullg?rd mans@mansr.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/