All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stanislav Meduna <stano@meduna.org>
To: Jacky Lam <lamshuyin@gmail.com>
Cc: "linux-rt-users@vger.kernel.org" <linux-rt-users@vger.kernel.org>
Subject: Re: Protection of critical section in PREEMPT_RT
Date: Wed, 06 Feb 2013 09:56:02 +0100	[thread overview]
Message-ID: <51121AA2.2080907@meduna.org> (raw)
In-Reply-To: <CAHX1yNSCba2wc7A2UOfdyzZ9z-YTYp+p16s8kHcA0e+r9sy+BQ@mail.gmail.com>

On 06.02.2013 02:59, Jacky Lam wrote:

> When driver code is reading the controller's registers and interrupt
> comes, interrupt handler (not the interrupt thread) need to clear the
> interrupt source first and return IRQ_WAKE_THREAD to wait for
> interrupt thread to actually handle the interrupt task. But in order
> to clear the interrupt source, I need to access the controller's
> internal registers. This is the problem I have now.

Maybe I am unterstanding this wrong, but shouldn't you unmask the
interrupt source when you are _done_ with processing the interrupt?

I have no real experience with interrupt driven drivers in RT-Linux,
but in other RTOSs I worked with this was the way to go -
the interrupt handler clears the source and schedules
the service thread but does not unmask the interrupt in question.
This is first done when the interrupt is processed.

That way you cannot be interrupted by the source you are
already processing. However, even that should IMHO work if the
locking is correct. Things can get complicated if you are
sharing interrupts between devices or if one device is accessed
with more drivers.

Do as Thomas is suggesting - turn all the CONFIG_DEBUG* on and
try with a non-RT kernel.

Regards
-- 
                                            Stano


  reply	other threads:[~2013-02-06  8:56 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-22  3:29 Protection of critical section in PREEMPT_RT Jacky Lam
2013-01-22 10:24 ` Stanislav Meduna
2013-01-31  9:27   ` Jacky Lam
2013-01-31 19:52     ` Frank Rowand
2013-02-04  7:27       ` Jacky Lam
2013-02-04 10:40         ` Thomas Gleixner
2013-02-05  1:40           ` Jacky Lam
2013-02-05 10:05             ` Thomas Gleixner
2013-02-06  1:59               ` Jacky Lam
2013-02-06  8:56                 ` Stanislav Meduna [this message]
2013-02-13 11:31                 ` Thomas Gleixner

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=51121AA2.2080907@meduna.org \
    --to=stano@meduna.org \
    --cc=lamshuyin@gmail.com \
    --cc=linux-rt-users@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.