linux-rt-users.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Ivo Sieben <meltedpianoman@gmail.com>
Cc: linux-serial@vger.kernel.org, Alan Cox <alan@linux.intel.com>,
	RT <linux-rt-users@vger.kernel.org>
Subject: Re: Deterministic behavior for TTY serial
Date: Thu, 19 Apr 2012 08:46:09 -0700	[thread overview]
Message-ID: <20120419154609.GA9263@kroah.com> (raw)
In-Reply-To: <CAMSQXEEkssPGWYgC4dkpKEhfrB4s8yOoxiNNVdRRX7r+b91EMQ@mail.gmail.com>

On Thu, Apr 19, 2012 at 05:37:56PM +0200, Ivo Sieben wrote:
> Hi Greg,
> 
> Op 19 april 2012 02:14 heeft Greg KH <gregkh@linuxfoundation.org> het
> volgende geschreven:
> > On Tue, Apr 17, 2012 at 04:38:30PM +0200, Ivo Sieben wrote:
> >> Hello,
> >>
> >> We are currently using the TTY framework for serial communication.
> >>
> >> We are wondering if it is possible to give the TTY device in more
> >> deterministic behavior (as in "less locks & no sleeping")
> >
> > What specifically are you looking for?
> >
> 
> We run an application with a real-time thread, running on a high priority.
> This thread does serial communication, using non blocking read/write
> file I/O on a tty device, with small amounts of data (= 24 bytes).
> This application runs on a AT2AM9261 processor, 200 MHz
> The maximum execution time of both the read & write go up to 200 us
> 
> >> So in case of non blocking read/write behavior:
> >> - We want directly write data to the serial_core transmit buffer and
> >> return immediately.
> >
> > What is "immediately"?
> >
> 
> We use non blocking read & write functions
> We would like the read/write functions to always execute less than 100us

Ok, and are you sure that your processor can even do something like
this?  Where is the time being spent when you make these calls?  A read
function should never hit the hardware, only retrieving data from a
buffer in memory, so if your processor can go this fast, it should be
fine.

Have you done profiling to determine exactly what it taking "too long"
for you?  If so, what is the delay?  If not, you should do this :)

> We use a self written serial_core device uart driver that implements a
> driver for a UART peripheral in a FPGA on our target board..

Do you have a pointer to the driver anywhere?  Why isn't it submitted
for inclusion in the main kernel tree?

thanks,

greg k-h

  reply	other threads:[~2012-04-19 15:46 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-17 14:38 Deterministic behavior for TTY serial Ivo Sieben
2012-04-19  0:14 ` Greg KH
2012-04-19 15:37   ` Ivo Sieben
2012-04-19 15:46     ` Greg KH [this message]
2012-04-26 14:27       ` Ivo Sieben
2012-05-01 14:30         ` Ivo Sieben
2012-05-01 15:04           ` Alan Cox
     [not found]             ` <CAMSQXEHAyPOF6YghsYmqqyx+N0oMgn5E=znhgFyspMUnaH78ig@mail.gmail.com>
2012-05-02  8:38               ` Ivo Sieben
2012-05-02 12:39                 ` Ivo Sieben
2012-05-03 15:28                   ` Ivo Sieben
2012-05-05  0:32                     ` Greg KH
2012-04-19 11:19 ` Alan Cox
2012-04-19 15:42   ` Ivo Sieben

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=20120419154609.GA9263@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=alan@linux.intel.com \
    --cc=linux-rt-users@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=meltedpianoman@gmail.com \
    /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;
as well as URLs for NNTP newsgroup(s).