From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752346AbdJSSEl (ORCPT ); Thu, 19 Oct 2017 14:04:41 -0400 Received: from mail-io0-f194.google.com ([209.85.223.194]:49173 "EHLO mail-io0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751966AbdJSSEi (ORCPT ); Thu, 19 Oct 2017 14:04:38 -0400 X-Google-Smtp-Source: ABhQp+RfOyExlAAegmiW6/XbmW7G9PDTUAE25RJD68GOVXc5c9txBHzeeZ8d7JZ99TtsadPQx6Hu2uviWBMfZSunX3k= MIME-Version: 1.0 In-Reply-To: <1769d82f-07d3-14c9-c06a-d6afec20fa0e@ti.com> References: <3806130.B2KCK0tvef@aspire.rjw.lan> <7b9c2a3e-2e88-938e-46a5-703de0080681@ti.com> <2926646.NJduVklg7n@aspire.rjw.lan> <1769d82f-07d3-14c9-c06a-d6afec20fa0e@ti.com> From: Ulf Hansson Date: Thu, 19 Oct 2017 20:04:36 +0200 Message-ID: Subject: Re: [PATCH 0/12] PM / sleep: Driver flags for system suspend/resume To: Grygorii Strashko 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 Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 19 October 2017 at 19:21, Grygorii Strashko wrote: > > > 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()). > Yeah, I had that feeling that omap has some trickyness going on. :-) I sure that can be fixed in the omap PM domain, although