On 10/19/2017 01:11 PM, Ulf Hansson wrote:

On 19 October 2017 at 20:04, Ulf Hansson [off-list ref] wrote:

quoted

On 19 October 2017 at 19:21, Grygorii Strashko [off-list ref] wrote:

quoted

On 10/19/2017 03:33 AM, Ulf Hansson wrote:

quoted

On 18 October 2017 at 23:48, Rafael J. Wysocki [off-list ref] wrote:

quoted

On Wednesday, October 18, 2017 9:45:11 PM CEST Grygorii Strashko wrote:

quoted

On 10/18/2017 09:11 AM, Ulf Hansson wrote:

[...]

quoted

quoted

quoted

quoted

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