From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753067AbdJSSBJ (ORCPT ); Thu, 19 Oct 2017 14:01:09 -0400 Received: from mail-it0-f49.google.com ([209.85.214.49]:47355 "EHLO mail-it0-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751969AbdJSSBH (ORCPT ); Thu, 19 Oct 2017 14:01:07 -0400 X-Google-Smtp-Source: ABhQp+SYPqws5B5diamagY5uO0ijqDObsStvxzrMXMYWoFkPuVGMRTCMafrpiPjb17hG5IkX/cYIGApCNQydNXdOnxA= MIME-Version: 1.0 In-Reply-To: References: <3806130.B2KCK0tvef@aspire.rjw.lan> <2890181.vdGMMavi5M@aspire.rjw.lan> <4337843.QuD5zygUhU@aspire.rjw.lan> From: Ulf Hansson Date: Thu, 19 Oct 2017 20:01:05 +0200 Message-ID: Subject: Re: [PATCH 0/12] PM / sleep: Driver flags for system suspend/resume To: "Rafael J. Wysocki" Cc: Linux PM , Bjorn Helgaas , Alan Stern , Greg Kroah-Hartman , LKML , Linux ACPI , Linux PCI , Linux Documentation , Mika Westerberg , Andy Shevchenko , Kevin Hilman , Wolfram Sang , "linux-i2c@vger.kernel.org" , Lee Jones Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org [...] >>> > Say you want to leave the parent suspended after system resume, but the >>> > child drivers use pm_runtime_force_suspend|resume(). The parent would then >>> > need to use pm_runtime_force_suspend|resume() too, no? >>> >>> Actually no. >>> >>> Currently the other options of "deferring resume" (not using >>> pm_runtime_force_*), is either using the "direct_complete" path or >>> similar to the approach you took for the i2c designware driver. >>> >>> Both cases should play nicely in combination of a child being managed >>> by pm_runtime_force_*. That's because only when the parent device is >>> kept runtime suspended during system suspend, resuming can be >>> deferred. >> >> And because the parent remains in runtime suspend late enough in the >> system suspend path, its children also are guaranteed to be suspended. > > Yes. > >> >> But then all of them need to be left in runtime suspend during system >> resume too, which is somewhat restrictive, because some drivers may >> want their devices to be resumed then. > > Actually, this scenario is also addressed when using the pm_runtime_force_*. > > The driver for the child would only need to bump the runtime PM usage > count (pm_runtime_get_noresume()) before calling > pm_runtime_force_suspend() at system suspend. That then also > propagates to the parent, leading to that both the parent and the > child will be resumed when pm_runtime_force_resume() is called for > them. I need to correct myself here. The above currently only works if the child is runtime resumed while pm_runtime_force_suspend() is called. The logic in pm_runtime_force_* needs to be improved to take care of such scenarios. However I think that should be rather easy to fix, if we want that. [...] Kind regards Uffe