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
next prev parent 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).