From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ulf Hansson Subject: Re: [PATCH 0/12] PM / sleep: Driver flags for system suspend/resume Date: Fri, 20 Oct 2017 08:05:17 +0200 Message-ID: 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> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org 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 List-Id: linux-acpi@vger.kernel.org [...] >>>>> 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 >> >> ...slipped with my fingers.. here is the rest of the reply... >> >> ..of course that require us to use another way for drivers to signal >> to the omap PM domain that it needs to stay powered as to deal with >> wakeup. >> >> I can have a look at that more closely, to see if it makes sense to change. >> > > Also, additional note here. some IPs are reused between OMAP/Davinci/Keystone, > OMAP PM domain have some code running at noirq time to dial with devices left > in PM runtime enabled state (OMAP PM runtime centric), while Davinci/Keystone haven't (clock_ops.c), > so pm_runtime_force_* API is actually possibility now to make the same driver work > on all these platforms. That sounds great! Also, in the end it would be nice to also convert the OMAP PM domain to genpd. I think most of the needed infrastructure is already there to do that. Kind regards Uffe