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 -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
