lkml.org 
[lkml]   [2011]   [Jan]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
Subjectinterrupt latency while resuming.

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.












\
 
 \ /
  Last update: 2011-01-08 18:01    [W:0.036 / U:0.636 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site