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