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
