在intel F10A进行DMA读写操作时,会首先调用queue_work函数将当前work压入工作队列中,然后调用wait_event_interruptible_timeout函数等待DMA读/写操作的完成,在调试的过程中偶尔会出现超时返回的情况。
下面结合Linux 3.9.6源码分析下wait_event_interruptible_timeout函数的实现,看看为什么会出现超时返回的情况。
#define wait_event_interruptible_timeout(wq, condition, timeout) ({ long __ret = timeout; if (!(condition)) __wait_event_interruptible_timeout(wq, condition, __ret); __ret; }) |
此宏的含义时在condition条件不满足的情况下调用__wait_event_interruptible_timeout函数,宏返回值为_ret。
#define __wait_event_interruptible_timeout(wq, condition, ret) do { DEFINE_WAIT(__wait); //初始化等待项
for (;;) { prepare_to_wait(&wq, &__wait, TASK_INTERRUPTIBLE); if (condition) break; if (!signal_pending(current)) { ret = schedule_timeout(ret); //睡眠ret时间 if (!ret) //返回值为0说明timeout时间到了,是超时返回的 break; continue; } ret = -ERESTARTSYS; break; } if (!ret && (condition)) ret = 1; finish_wait(&wq, &__wait); } while (0) |
首先调用DEFINE_WAIT初始化等待项__wait。等待队列用于进程等待某一特定事件的发生,这里就是等待DMA读写操作的完成。
prepare_to_wait函数在这里会将__wait加入等待队列wq,并设置当前进程的状态为TASK_INTERRUPTIBLE(可中断状态),此状态的进程可以被信号和中断打断。
signal_pending判断当前进程是否有未处理的信号。这里是如果有未处理的信号,就设置ret为-ERESTARTSYS,并跳出for循环。如果没有信号需要处理,就调用schedule_timeout函数。schedule_timeout函数的主体代码片段如下:
expire = timeout + jiffies;
setup_timer_on_stack(&timer, process_timeout, (unsigned long)current); //创建timer __mod_timer(&timer, expire, false, TIMER_NOT_PINNED); schedule(); del_singleshot_timer_sync(&timer);
/* Remove the timer from the object tracker */ destroy_timer_on_stack(&timer);
timeout = expire - jiffies; //返回值 |
schedule_timeout函数的功能就是让进程睡眠指定的timeout时间。schedule_timeout函数这里使用timer机制来完成,timer是在时钟中断中调用。这里首先将当前jiffies值加上timeout时间即为timer的到期时间,然后调用setup_timer_on_stack函数创建timer,timer会在时间到期之后调用process_timeout函数,传入process_timeout函数的参数为当前进程current。
schedule函数会将状态为TASK_INTERRUPTIBLE的当前进程从运行队列中删除,这样此进程就不会再参与调度,那么如何保证在timeout时间到之后能够此进程得到调度执行呢?process_timeout函数就调用wake_up_process函数将当前进程current唤醒,即将current进程加入运行队列runqueue中。
schedule_timeout函数的返回值是将到期时间expire值减current进程schedule回来时的jiffies值,正常情况下没有别的地方调用wake_up唤醒此进程,则返回值等于0;如果被别的地方提前wake_up唤醒,那么返回值就是剩下的时间。
现在回过来接着看__wait_event_interruptible_timeout宏。在schedule_timeout函数返回后会判断返回值ret,如果ret值为0,说明是timeout睡眠时间到了,是超时返回的,这样就直接跳出for循环,不再睡眠等待;如果ret值不为0,说明是在另外的地方wake_up唤醒了current进程,这种情况下会continue循环,会再一次的将等待项__wait加入等待队列wq中,然后判断condition条件是否满足,如果满足则终止循环,否则接着之前的流程调用schedule_timeout函数睡眠。
从上面的分析可以看出一个调用wait_event_interruptible_timeout的进程,被唤醒调度执行,需要满足两个条件:1)condition条件满足;2)调用wake_up唤醒。如果仅仅是修改了condition,使得condition条件为真,但由于此时调用wait_event_interruptible_timeout函数的进程不在运行队列runqueue中,因此不会被调度,这种情况还需要一个wake_up来讲此进行加入runqueue中。
在调试过程中偶尔出现超时返回的情况,是由于Intel F10A的驱动每次DMA传输最多只能传输512KB,这样如果传入内容达到10M左右的时候,会分成多次DMA传输,而每次DMA传输的工作是在workqueue中实现的,每次DMA完成收到中断之后,在中断处理函数中会调度workqueue中work执行,这个调度执行时间是不可控的,这样多次DMA传输的时间在系统比较繁忙的时候就可能出现超出我们在wait_event_interruptible_timeout函数中设定的超时时间。