On Fri, Aug 21 2015 at 15:04 -0600, Kevin Hilman wrote:

Geert Uytterhoeven [off-list ref] writes:

quoted

Hi Kevin,

On Fri, Aug 14, 2015 at 7:19 PM, Kevin Hilman [off-list ref] wrote:

quoted

On Fri, Aug 14, 2015 at 12:24 AM, Geert Uytterhoeven
[off-list ref] wrote:

quoted

On Fri, Aug 14, 2015 at 5:40 AM, Kevin Hilman [off-list ref] wrote:

quoted

Geert Uytterhoeven [off-list ref] writes:

quoted

On Wed, Aug 12, 2015 at 9:50 PM, Kevin Hilman [off-list ref] wrote:

quoted

This check might have made sense before PM domains, but with PM domains,
it's entirely possible to have a simple device without a driver and the
PM domain handles all the necesary PM, so I think this check
could/should be removed.

Thoughts?

Simple devices without a driver aren't handled automatically.
At minimum, the driver should call pm_runtime_enable(), cfr.
drivers/bus/simple-pm-bus.c.

That's correct, and in the proof-of-concept stuff I hacked up and in
Lina's series, the CPU "devices" do indeed to this.  Without that, they
wouldn't end up ever taking this codepath through genpd's
runtime_suspend and power_off hooks.

Also, I'm not sure if your comment was meant to be an objection to the
patch?  or if you're OK with it.

My comment was purely meant as a response to "it's entirely possible to have a
simple device without a driver and the PM domain handles all the necesary PM".

Right, so if the PM domain does the pm_runtime_enable() for these
"simple" devices without drivers, they can still exist without a
driver, and the PM domain doing all the magic.

Is it possible to let the PM Domain do the pm_runtime_enable() itself in
the absence of a driver?

Well, I suppose it's possible, not sure it's recommended. :)

quoted

If yes, I wouldn't have needed simple-pm-bus.c.
What if a driver is bound later?

Yeah, you're approach is better.

I am not sure I understand the approach? Initialize the CPU devices as
"simple-pm-bus" compatible?

Thanks,
Lina