Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751733AbdIUJ1Z (ORCPT ); Thu, 21 Sep 2017 05:27:25 -0400 Received: from mail.sig21.net ([80.244.240.74]:44105 "EHLO mail.sig21.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751387AbdIUJ1X (ORCPT ); Thu, 21 Sep 2017 05:27:23 -0400 Date: Thu, 21 Sep 2017 11:27:13 +0200 From: Johannes Stezenbach To: "Rafael J. Wysocki" Cc: Ulf Hansson , "Rafael J. Wysocki" , Linux PM , Alan Stern , Mika Westerberg , Andy Shevchenko , Kevin Hilman , LKML Subject: Re: [PATCH] PM: Document rules on using pm_runtime_resume() in system suspend callbacks Message-ID: <20170921092713.tqnclpljoraesene@sig21.net> References: <1849600.vI30ccvhCD@aspire.rjw.lan> <20170920162731.wopbh7iwggu2xouk@sig21.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170609 (1.8.3) X-Spam-21-Score: -2.9 (--) X-Spam-21-Report: No, score=-2.9 required=8.0 tests=ALL_TRUSTED=-1,BAYES_00=-1.9 autolearn=ham autolearn_force=no Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2396 Lines: 61 On Thu, Sep 21, 2017 at 02:39:30AM +0200, Rafael J. Wysocki wrote: > On Wed, Sep 20, 2017 at 6:27 PM, Johannes Stezenbach wrote: > > > > E.g. an audio codec could keep running > > while the i2c bus used to program its registers can be runtime suspended. > > If this is correct I think it would be useful to spell it out explicitly > > in the documentation. > > That's because the i2c bus uses the ignore_children flag that allows > it to override the general rules. :-) Ah! I was looking at Documentation/driver-api/pm only (which is changed by your patch), but this is documented in Documentation/power (and obviously I hadn't checked the code, shame on me). > direct_complete has nothing to do with this. Oh? Reading again, do I get this right: 1. simple method: always call pm_runtime_resume() in ->suspend(), then suspend the driver again 2. optimization: if pm_runtime_suspended(), the driver's ->suspend() can possibly do nothing if conditions permit, otherwise it calls pm_runtime_resume() and then suspends 3. optimization: tell pm core to skip ->suspend() via return value from ->prepare() which sets direct_complete ...and your patch only deals with 1 and 2. Sorry to hijack your thread for side discussion, it was inadvertant due to my lack of understanding. > First off, the PM core does check the direct_complete flag in > __device_suspend() and does more-or-less what you are saying. > > However, that flag is initialized in device_prepare() with the help of > the ->suspend() return value, because whether or not it makes sense to you mean ->prepare(), right? > set that flag depends on some conditions that may change between > consecutive system suspend-resume cycles in general and need to be > checked in advance before setting it. > > HTH It does, however the question remains *why* it needs to check it in ->prepare() and not right before calling ->suspend(). Using ->prepare() for the purpose seems wrong since it traverses the hierarchy in the "wrong" order. Only right before calling ->suspend() the driver knows if its current state allows it to skip any further actions for suspend, because suspending children or other users may cause pm_runtime_resume() for it. (In the back of my head I have the scenario of bug #196861, some completely different driver uses i2c via ACPI OpRegion during its suspend.) Thanks, Johannes