On 10/19/2017 01:11 PM, Ulf Hansson wrote: > On 19 October 2017 at 20:04, Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote: >> On 19 October 2017 at 19:21, Grygorii Strashko <grygorii.strashko@xxxxxx> wrote: >>> >>> >>> On 10/19/2017 03:33 AM, Ulf Hansson wrote: >>>> On 18 October 2017 at 23:48, Rafael J. Wysocki <rjw@xxxxxxxxxxxxx> 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 > > ...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. -- regards, -grygorii
