[...]

quoted

As you probably figured out from my above comments, the solution here
isn't really working.

Adding these new APIs, more or less requires us to manage reference
counting on the genpd for the device.

Hmm, I am not able to understand why would we need that with this series :(

quoted

I haven't thought about that in
great detail, just that we of course need to be careful if we want to
introduce something like that, to make sure all aspect of locking
becomes correct.

Moreover adding reference counting touches the idea of adding APIs to
genpd, to allow users/drivers to control their genpd explicitly. This
is required to support > 1 pm_domain per device. I assume you have
been following that discussion for genpd on linux-pm as well. My point
is that, we should consider that while inventing *any* new APIs.

Not very deeply but yeah I have seen that thread.

So, I couldn't find way to get the locking thing fixed to avoid deadlocks but we
can live with a constraint (if you guys think it is fine) to have this solved.

Constraint: Update performance state API wouldn't support power domains that
don't provide a set_performance_state() callback and have multiple parent power
domains.

No thanks.

If we are going to do this, let's do it properly. To me some minor
constraints would be okay, but this is just too much.

Why: In order to guarantee that we read and update the performance_state of
subdomains and devices properly, we need to do that under the parent domain's
lock. And if we have multiple parent power domains, then we would be required to
get them locked at once before updating subdomain's state and that would be a
nightmare.

It's not a nightmare, just a tricky thing to solve. :-)

[...]

Kind regards
Uffe