Messages in this thread | | | Date | Thu, 20 Jun 2013 16:17:58 +0530 | From | pankaj chauhan <> | Subject | Re: [PATCH 1/5] drivers/misc: Support for RF interface device framework |
| |
On 6/19/2013 5:01 PM, Lars-Peter Clausen wrote: > On 06/18/2013 09:44 AM, Akhil Goyal wrote: > [...] >>>> + /* >>>> + * Spin_locks are changed to mutexes if PREEMPT_RT is enabled, >>>> + * i.e they can sleep. This fact is problem for us because >>>> + * add_wait_queue()/wake_up_all() takes wait queue spin lock. >>>> + * Since spin lock can sleep with PREEMPT_RT, wake_up_all() can not be >>>> + * called from rf_notify_dl_tti (which is called in interrupt context). >>>> + * As a workaround, wait_q_lock is used for protecting the wait_q and >>>> + * add_wait_queue_locked()/ wake_up_locked() functions of wait queues >>>> + * are used. >>>> + */ >>>> + raw_spin_lock_irqsave(&rf_dev->wait_q_lock, flags); >>>> + __add_wait_queue_tail_exclusive(&rf_dev->wait_q,&wait); >>>> + raw_spin_unlock_irqrestore(&rf_dev->wait_q_lock, flags); >>>> + set_current_state(TASK_INTERRUPTIBLE); >>>> + /*Now wait here, tti notificaion will wake us up*/ >>>> + schedule(); >>>> + set_current_state(TASK_RUNNING); >>>> + raw_spin_lock_irqsave(&rf_dev->wait_q_lock, flags); >>>> + __remove_wait_queue(&rf_dev->wait_q,&wait); >>>> + raw_spin_unlock_irqrestore(&rf_dev->wait_q_lock, flags); >>> >>> This is not a proper method of waiting for an event. Why can't you >>> use wait_event() here? >> wait_event() is internally calling spin_lock_irqsave() and this function >> will be called in hard IRQ context with PREEMPT_RT enabled(IRQF_NODELAY >> set). So wait_event cannot be used. >> This problem can be solved if we can get the following patch applied on the >> tree. >> https://patchwork.kernel.org/patch/2161261/ >> >>> >>> The explanation about the interrupt handler seems incorrect, since PREEMPT_RT >>> also turns interrupt handlers into threads. >> The interrupt handler has real time requirement and thus running in HARDIRQ >> context with flag IRQF_NODELAY. We get this interrupt in every millisecond. > > But if you are running in HARDIRQ context the whole sequence doesn't make > much sense at all, since you won't be able to sleep and wait for the event. >
This function for adding process to rf_dev->wait_q runs in process context, but the function (dl_notify_tti())which wakes process up from this queue runs in HARDIRQ context, that's why we could not use wait_event() or spin_lock() here.
thanks, pankaj
| |