On 30-07-20, 10:01, Stephan Gerhold wrote: > dev_pm_opp_attach_genpd() allows attaching an arbitrary number of > power domains to an OPP table. In that case, the genpd core will > create a virtual device for each of the power domains. > > At the moment, the OPP core only calls > dev_pm_genpd_set_performance_state() on these virtual devices. > It does not attempt to power on the power domains. Therefore > the required power domain might never get turned on. > > So far, dev_pm_opp_attach_genpd() is only used in qcom-cpufreq-nvmem.c > to attach the CPR power domain to the CPU OPP table. The CPR driver > does not check if it was actually powered on so this did not cause > any problems. However, other drivers (e.g. rpmpd) might ignore the > performance state until the power domain is actually powered on. > > Since these virtual devices are managed exclusively by the OPP core, > I would say that it should also be responsible to ensure they are > enabled. A similar approach is already used for regulators, see > commit 8d45719caaf5 ("opp: core: add regulators enable and disable"). > > This commit implements similar functionality for the virtual genpd > devices managed by the OPP core. The power domains are turned on > the first time dev_pm_opp_set_rate() is called. They are turned off > again when dev_pm_opp_set_rate(dev, 0) is called. > > Signed-off-by: Stephan Gerhold <step...@gerhold.net> > --- > Related discussion: > https://lore.kernel.org/linux-arm-msm/20200426123140.ga190...@gerhold.net/ > > There would be also other ways to implement this, e.g. device links, > assuming that the device using the OPP table also makes use of runtime PM. > My first thought was that it would be most consistent to handle this like > regulators, bandwidth votes etc. RFC :)
This stuff was done ages back and I am starting to forget almost everything now :) Ulf, why doesn't pm_runtime_get(dev) take care of enabling multiple power domain case ? RFP (request for patience) :) -- viresh