Linux Serial subsystem development
 help / color / mirror / Atom feed
From: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
To: Mason <slash.tmp@free.fr>
Cc: linux-serial@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
	Peter Hurley <peter@hurleysoftware.com>,
	Mans Rullgard <mans@mansr.com>
Subject: Re: Hardware spec prevents optimal performance in device driver
Date: Sat, 9 May 2015 18:32:54 +0100	[thread overview]
Message-ID: <20150509183254.18b786f9@lxorguk.ukuu.org.uk> (raw)
In-Reply-To: <554DDFF3.5060906@free.fr>

On Sat, 09 May 2015 12:22:43 +0200
Mason <slash.tmp@free.fr> wrote:

> Hello everyone,
> 
> 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.

FIFOs on sane serial ports either have an adjustable threshold or fire
when its some way off empty. That way our normal flow is that you take
the TX interrupt before the port empties so you can fill it back up.

On that kind of port I'd expect optimal to probably be something like
writing 4 bytes until < 4 is left, and repeating that until your own
transmit queue is < 4 bytes and the write the dribble.

You don't normally want to perfectly fill the FIFO, you just want to ram
stuff into it efficiently with sufficient hardware queue and latency of
response that the queue never empties. Beyond that it doesn't matter.

Alan

  reply	other threads:[~2015-05-09 17:32 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-09 10:22 Hardware spec prevents optimal performance in device driver Mason
2015-05-09 17:32 ` One Thousand Gnomes [this message]
2015-05-09 20:48   ` Mason
2015-05-10 10:29     ` Måns Rullgård
2015-05-10 16:46       ` Mason

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150509183254.18b786f9@lxorguk.ukuu.org.uk \
    --to=gnomes@lxorguk.ukuu.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=mans@mansr.com \
    --cc=peter@hurleysoftware.com \
    --cc=slash.tmp@free.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox