linux-rt-users.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Ivo Sieben <meltedpianoman@gmail.com>
Cc: RT <linux-rt-users@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
	Steven Rostedt <rostedt@goodmis.org>
Subject: Re: [PATCH-v2] Set irq thread to RT priority on creation
Date: Mon, 3 Jun 2013 16:45:56 +0200 (CEST)	[thread overview]
Message-ID: <alpine.LFD.2.02.1306031637420.2905@ionos> (raw)
In-Reply-To: <1370254322-17240-1-git-send-email-meltedpianoman@gmail.com>

On Mon, 3 Jun 2013, Ivo Sieben wrote:

> When a threaded irq handler is installed the irq thread is initially created
> on normal scheduling priority. Only after the the irq thread is woken up it
> immediately sets its priority to RT_FIFO MAX_USER_RT_PRIO/2.
> 
> This means that interrupts that occur directly after the irq handler is
> installed will be handled on a normal scheduling priority instead of the
> realtime priority that you would expect. Fixed this by setting the RT
> priority on creation of the irq_thread.
> 
> This solves the following issue with a UART device driver:
> On start of the application there is already data present in the uart RX
> fifo buffer. On opening the uart device the hard & threaded interrupt
> handlers are installed and the interrupts are enabled. Immediately a hard
> irq occurs because there is still data in the RX fifo. Because the threaded
> irq handler is still on normal scheduling, my application is not immediatly
> interrupted by the threaded handler and continues to run: it tries to flush
> the uart input buffer and writes data to the uart device. After this the
> threaded handler finally gets scheduled in and fills the buffer with the
> "old" received data. When my application reads data from the uart port it
> receives the "old" data and gives an error.

While I in principle agree with the patch, the issue you are
describing is just solved accidentaly.

The question is why there is data present in the UART when the UART
driver has not initialized the UART. Up to the point where the UART is
opened and the interrupt handler is installed the receiver should be
disabled. Also there is the question why a flush does not kill
everything including the pending data in the UART itself.

And I don't think, that your issue is solved completely. Assume the
following:

Open UART
Flush Buffers (including UART fifo)

---> UART receives data
---> Interrupt
	Data is available in tty buffer

Write data to UART

Receive data from UART

You still get data which got into the buffer before you sent stuff
out. So your application should not be surpriced at all by random data
on the receive line when it starts up.

Thanks,

	tglx

  reply	other threads:[~2013-06-03 14:45 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-30 12:12 [PATCH] RFC: Set irq thread to RT priority on creation Ivo Sieben
2013-05-30 14:07 ` Thomas Gleixner
2013-05-30 14:54   ` Steven Rostedt
2013-05-30 19:50     ` Thomas Gleixner
2013-06-03 10:12       ` [PATCH-v2] " Ivo Sieben
2013-06-03 14:45         ` Thomas Gleixner [this message]
2013-06-05  6:46           ` Ivo Sieben
2013-06-14 15:33         ` Sebastian Andrzej Siewior
2013-05-30 14:53 ` [PATCH] RFC: " Steven Rostedt

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=alpine.LFD.2.02.1306031637420.2905@ionos \
    --to=tglx@linutronix.de \
    --cc=bigeasy@linutronix.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rt-users@vger.kernel.org \
    --cc=meltedpianoman@gmail.com \
    --cc=rostedt@goodmis.org \
    /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).