Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S936684AbcKKTre (ORCPT ); Fri, 11 Nov 2016 14:47:34 -0500 Received: from mail-pg0-f54.google.com ([74.125.83.54]:33713 "EHLO mail-pg0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932697AbcKKTrc (ORCPT ); Fri, 11 Nov 2016 14:47:32 -0500 X-Greylist: delayed 406 seconds by postgrey-1.27 at vger.kernel.org; Fri, 11 Nov 2016 14:47:32 EST Date: Fri, 11 Nov 2016 11:40:42 -0800 From: Brian Norris To: Tony Lindgren Cc: Dmitry Torokhov , "Rafael J . Wysocki" , Pavel Machek , Len Brown , Greg Kroah-Hartman , lkml , Brian Norris , "linux-pm@vger.kernel.org" Subject: Re: [PATCH] PM / wakeirq: report wakeup events in dedicated wake-IRQs Message-ID: <20161111194041.GA111624@google.com> References: <1478801227-65527-1-git-send-email-briannorris@chromium.org> <20161110184910.GA135921@google.com> <20161110204911.GK27724@atomide.com> <20161110213038.GA108490@google.com> <20161111164753.GD7138@atomide.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161111164753.GD7138@atomide.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1668 Lines: 36 On Fri, Nov 11, 2016 at 08:47:54AM -0800, Tony Lindgren wrote: > But sounds like the threaded IRQ is not your concern and you mostly Right, threaded is OK for this; it's not performance critical. It just highlighted the fact that its completion is not synchronized with anything. > care about getting the right time for the wake up interrupt. Not "time", per se, but blame. But that blame is timing related: if it comes after the system finished resuming, then it's useless, since user-space won't know to come back and check later. > The wakeup interrupt controller knows something happened earlier, > so maybe it could report that time if queried somehow? Sort of. We have /sys/power/pm_wakeup_irq already. But it's really less useful to get IRQ-level stats for this, than to get device info. AFAICT, there's no machine-readable association between IRQs and devices; the best you can get is by parsing the names in /proc/interrupts. Or, if we really want to say that's sufficient, then maybe we should kill all the device-level wakeup stats in sysfs... (Is that what the flamewar was all about? I hope I'm not poking the hornet's nest.) BTW, for context, I'm working on using dev_pm_set_dedicated_wake_irq() for a Wifi driver which supports out-of-band (e.g., GPIO-based) wakeup. I see it's used in the I2C core, but the I2C code never actually calls dev_pm_enable_wake_irq(). So while I think I can use this API OK for my Wifi driver (calling dev_pm_{en,dis}able_wake_irq() at system suspend/resume), I'm not sure this will help the I2C case. The more I look at this API, the more I'm confused, especially about its seeming dependence on runtime PM. Brian