Re: lazy disabling and idle states

[Thomas Gleixner]

Hi,

On Thu, 2 Sep 2010, Abhijeet Dharmapurikar wrote:

> I understand that lazy disabling was introduced so that we don't loose wakeup
> interrupts while going in to suspend. The way lazy disabling is implemented is

No, that's wrong. lazy irq disabling has nothing to do with suspend at
all. It's there to avoid expensive access to interrupt controller
hardware. In most cases when an interrupt is disabled via
disable_irq(), then the device does not issue an interrupt, so we
optimize that case and do the lazy disable. The suspend code just
utilizes this detail.

If a driver is shutdown completely and called free_irq() then the irq
line is disabled at the hardware level in any case.

> in disable_irq() the interrupt is marked as IRQ_DISABLED but the irq_chip's
> mask function is not called. As a result the interrupt remains enabled in the
> irq controller and is masked in the controller only when it is raised again.
> 
> This raises the question of unnecessary wakeups in idle power collapse case.
> By idle power collapse I mean the low power state where the processor is shut
> off during long idle periods. While in idle power collapse, the cpu could wake
> up from a disabled interrupt only to realize that it was marked IRQ_DISABLED
> (as a part of lazy disabling) and would call the mask function and go to idle
> power collapse again. This behavior could have negative effect on power
> consumption.
> 
> One solution that comes to mind is that the idle power collapse code, before
> going to sleep, could iterate over the irq_desc's of all the interrupts and
> call mask on the ones marked as IRQ_DISABLED to make sure that they are
> actually masked in the controller. This would fix the unnecessary wakeups from
> idle power collapse. But this operation is very lengthy and inefficient
> because it may end up calling mask on interrupts that have been already
> masked.
> 
> Are there other solutions to address this issue? Feel free to correct me if I
> missed a something and my conclusion is incorrect.

Fix the device drivers which keep a device in a state which will fire
interrupts after the driver called disable_irq(). 
 
Thanks,

	tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/