[...]
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 :(
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