interrupt latency while resuming.

[Abhijeet Dharmapurikar <adharmap@codeaurora.org>]

I am trying to address an issue of not handling a wakeup interrupt quick 
enough while resuming. It is an edge triggered interrupt with the 
IRQ_WAKEUP flag set. The interrupt controller implements lazy disabling 
of interrupts, IOW does not have a disable callback in the irq_chip.

So while going in to supend that interrupt is marked  IRQ_DISABLED in 
dpm_suspend_noirq().

On resume handle_edge_trigger is run right after 
arch_suspend_enable_irqs(). It finds the interrupt marked  IRQ_DISABLED 
and it sets the IRQ_PENDING flag and does not call the handler.

As the resume path unrolls, non boot cpus  are enabled, 
dpm_resume_noirq() is run. At that time it finds the IRQ_PENDING flag is 
set on this interrupt and the interrupt handler is run.

The problem is, this is very late for the interrupt to be run. Possibly 
because enable_nonboot_cpu takes a while or the resume_noirq callbacks 
take a long time etc.

I tried using IRQF_NO_SUSPEND for that interrupt and it seems the 
interrupt is handled as soon as arch_suspend_enable_irqs() is run.
However I suspect that with this the system will fail to abort suspend - 
The interrupt could trigger between dpm_suspend_noirq() and 
arch_suspend_disable_irqs() and since it wont be marked IRQF_PENDING the 
system goes to suspend never to be woken up again. (the check to abort 
suspend because of a pending interrupt is done in check_wakeup_irqs() in 
sysdev_suspend). I dont think IRQF_NO_SUSPEND was designed for wakeup 
interrupts. Please correct me if I am missing something here.

A solution that comes to mind is enabling such interrupts right before 
arch_suspend_enable_irqs() is run. In some more detail, mark these 
interrupts as IRQF_LOW_SUSPEND_LATENCY in their irq_desc->status and 
enable such interrupts before doing arch_suspend_enable_irqs(). That way 
when arch_suspend_enable_irqs() happens, the handler is run immediately.
We skip enabling such interrupts in resume_device_irqs() to avoid 
enabling them twice.

Will appreciate any other suggestions towards fixing the delay.

Abhijeet

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.