From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755306AbdJSRVg (ORCPT ); Thu, 19 Oct 2017 13:21:36 -0400 Received: from lelnx193.ext.ti.com ([198.47.27.77]:25556 "EHLO lelnx193.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754599AbdJSRVb (ORCPT ); Thu, 19 Oct 2017 13:21:31 -0400 Subject: Re: [PATCH 0/12] PM / sleep: Driver flags for system suspend/resume To: Ulf Hansson CC: Linux PM , "Rafael J. Wysocki" , 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 References: <3806130.B2KCK0tvef@aspire.rjw.lan> <7b9c2a3e-2e88-938e-46a5-703de0080681@ti.com> <2926646.NJduVklg7n@aspire.rjw.lan> From: Grygorii Strashko Message-ID: <1769d82f-07d3-14c9-c06a-d6afec20fa0e@ti.com> Date: Thu, 19 Oct 2017 12:21:08 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [128.247.59.147] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10/19/2017 03:33 AM, Ulf Hansson wrote: > On 18 October 2017 at 23:48, Rafael J. Wysocki wrote: >> On Wednesday, October 18, 2017 9:45:11 PM CEST Grygorii Strashko wrote: >>> >>> On 10/18/2017 09:11 AM, Ulf Hansson wrote: >> >> [...] >> >>>>>> That's the point. We know pm_runtime_force_* works nicely for the >>>>>> trivial middle-layer cases. >>>>> >>>>> In which cases the middle-layer callbacks don't exist, so it's just like >>>>> reusing driver callbacks directly. :-) >>> >>> I'd like to ask you clarify one point here and provide some info which I hope can be useful - >>> what's exactly means "trivial middle-layer cases"? >>> >>> Is it when systems use "drivers/base/power/clock_ops.c - Generic clock >>> manipulation PM callbacks" as dev_pm_domain (arm davinci/keystone), or OMAP >>> device framework struct dev_pm_domain omap_device_pm_domain >>> (arm/mach-omap2/omap_device.c) or static const struct dev_pm_ops >>> tegra_aconnect_pm_ops? >>> >>> if yes all above have PM runtime callbacks. >> >> Trivial ones don't actually do anything meaningful in their PM callbacks. >> >> Things like the platform bus type, spi bus type, i2c bus type and similar. >> >> If the middle-layer callbacks manipulate devices in a significant way, then >> they aren't trivial. > > I fully agree with Rafael's description above, but let me also clarify > one more thing. > > We have also been discussing PM domains as being trivial and > non-trivial. In some statements I even think the PM domain has been a > part the middle-layer terminology, which may have been a bit > confusing. > > In this regards as we consider genpd being a trivial PM domain, those > examples your bring up above is too me also examples of trivial PM > domains. Especially because they don't deal with wakeups, as that is > taken care of by the drivers, right!? Not directly, for example, omap device framework has noirq callback implemented which forcibly disable all devices which are not PM runtime suspended. while doing this it calls drivers PM .runtime_suspend() which may return non 0 value and in this case device will be left enabled (powered) at suspend for wake up purposes (see _od_suspend_noirq()). -- regards, -grygorii