今天在寫觸控式螢幕驅動時在中斷處理函數中使用disable_irq關中斷發現在進入中斷處理後內核就掛掉了,於是研究了一下才發現disable_irq關閉中斷並等待中斷處理完後返回, 而disable_irq_nosync立即返回. 在中斷處理常式中應該使用disable_irq_nosync來關閉中斷
先看一下disable_irq_nosync,內核代碼中是這樣解釋的:
/** * disable_irq_nosync - disable an irq without waiting * @irq: Interrupt to disable * * Disable the selected interrupt line. Disablesand Enables are * nested. * Unlike disable_irq(),this function doesnot ensure existing * instances of the IRQ handler have completed before returning. * * This function may be called from IRQ context. */ void disable_irq_nosync(unsigned int irq) { struct irq_desc *desc = irq_to_desc(irq); unsigned long flags; if(!desc) return; chip_bus_lock(irq, desc); spin_lock_irqsave(&desc->lock, flags); __disable_irq(desc, irq, false); spin_unlock_irqrestore(&desc->lock, flags); chip_bus_sync_unlock(irq, desc); }
|
關閉中斷後程式返回, 如果在中斷處理常式中, 那麼會繼續將中斷處理常式執行完.
void disable_irq(unsignedint irq) { struct irq_desc *desc = irq_desc + irq; if(irq>= NR_IRQS) return; disable_irq_nosync(irq); if(desc->action) synchronize_irq(irq); }
|
關閉中斷並等待中斷處理完後返回.從代碼中可以看到, disable_irq先是調用了disable_irq_nosync, 然後檢測desc->action是否為1. 在中斷處理常式中, action是置1的, 所以進入synchronize_irq函數中.
void synchronize_irq(unsignedint irq) { struct irq_desc *desc= irq_to_desc(irq); unsignedint status; if(!desc) return; do{ unsignedlong flags; while(desc->status& IRQ_INPROGRESS) cpu_relax(); spin_lock_irqsave(&desc->lock, flags); status = desc->status; spin_unlock_irqrestore(&desc->lock, flags); }while(status & IRQ_INPROGRESS); wait_event(desc->wait_for_threads,!atomic_read(&desc->threads_active)); }
|
注釋中說明該函數是在等待中斷處理常式的結束, 這也是disable_irq與disable_irq_nosync不同的主要所在. 但是在中斷處理函數中調用會發生什麼情況呢? 進入中斷處理函數前IRQ_INPROGRESS會被__setup_irq設置, 所以程式會一直陷在while迴圈中, 而此時內核以經被獨佔, 這就導致系統死掉.
總結:
由於在disable_irq中會調用synchronize_irq函數等待中斷返回, 所以在中斷處理常式中不能使用disable_irq, 否則會導致cpu被synchronize_irq獨佔而發生系統崩潰.
http://changyang319.pixnet.net/
留言列表