Thanks, that's helpful.
Wouldn't it also be possible to make my own version of
prepare_to_wait()/finish_wait()/wake_up() etc. which internally
use a raw spinlock instead of a normal one?
- Till
On 11/08/2012 10:08 PM, Josh Cartwright wrote:
On Thu, Nov 08, 2012 at 04:28:48PM -0600, Till Straumann wrote:
Hello list.
I have a driver which is designed to do most work in user-space.
The ISR is really simple. It just ACKs/clears the interrupt and
then should unblock a waiting thread.
It seems overkill (and costs me about 5-10us) to use a threaded
interrupt in such a case (hard isr unblocks a kthread whose only
'work' is unblocking another (user) thread).
I have found some references where users try to do a similar
thing via UIO
(e.g.,
http://article.gmane.org/gmane.linux.rt.user/7372/
http://article.gmane.org/gmane.linux.rt.user/7676)
However, the succinct answer was along the line 'that can't work with UIO'.
IMHO it would be very helpful to get a more detailed explanation
as to why it doesn't work (i.e., what things you are and are not
allowed to do from a hard-isr under RT_PREEMPT). I suspect it is
because UIO calls routines such as 'kill_fasync' which use
ordinary (as opposed to raw) spinlocks which means that the
caller could be preempted (under RT_PREEMPT), right?
Correct. Not just kill_fasync(), but the use of
wake_up_interruptible() as well (and maybe others).
What *is* the recommended mechanism to wake up a thread from
a hard-isr?
I'd suggest you look at the hrtimer_sleeper code for an example of
process wakeup done in hardirq context. (hint, the low-level answer to
your question is wake_up_process()).
Josh
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html