From mboxrd@z Thu Jan 1 00:00:00 1970 From: Abhijeet Dharmapurikar Subject: interrupt latency while resuming. Date: Sat, 08 Jan 2011 08:58:57 -0800 Message-ID: <4D2897D1.3040609@codeaurora.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: Sender: linux-kernel-owner@vger.kernel.org To: tglx@linutronix.de Cc: "Rafael J. Wysocki" , Andrew Morton , Russell King , Greg Kroah-Hartman , Alan Stern , linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org List-Id: linux-arm-msm@vger.kernel.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.