On Thu, 12 Aug 2021 at 15:21, Dmitry Baryshkov <dmitry.baryshkov@xxxxxxxxxx> wrote: > > On 03/07/2021 05:54, Bjorn Andersson wrote: > > The general expectation is that powering on a power-domain should make > > the power domain deliver some power, and if a specific performace state > > is needed further requests has to be made. > > > > But in contrast with other power-domain implementations (e.g. rpmpd) the > > RPMh does not have an interface to enable the power, so the driver has > > to vote for a particular corner (performance level) in rpmh_power_on(). > > > > But the corner is never initialized, so a typical request to simply > > enable the power domain would not actually turn on the hardware. Further > > more, when no more clients vote for a performance state (i.e. the > > aggregated vote is 0) the power domain would be turn off. > > > > Fix both of these issues by always voting for a corner with non-zero > > value, when the power domain is enabled. > > > > The tracking of the lowest non-zero corner is performed to handle the > > corner case if there's ever a domain with a non-zero lowest corner, in > > which case both rpmh_power_on() and rpmh_rpmhpd_set_performance_state() > > would be allowed to use this lowest corner. > > > > Fixes: 279b7e8a62cc ("soc: qcom: rpmhpd: Add RPMh power domain driver") > > Signed-off-by: Bjorn Andersson <bjorn.andersson@xxxxxxxxxx> > > --- > > > > Resending because the hunk in rpmhpd_update_level_mapping() was left in the > > index. > > So, colleagues, what is the fate of this patch? Is it going to be > applied? Or we agree that current approach (power_on + > set_performance_state) is the expected behaviour? My patches on gdsc > rework depend on this patch, but I can rework in them in favour of > required-opp approach. Today, genpd treats performance states and power on/off states as orthogonal. You know this already, ofcourse. Although, to clarify, this means that the genpd provider has to deal with the scenario when its ->set_performance_state() callback may be invoked, while the PM domain is turned off, for example. Similarly, genpd may power on the PM domain by invoking the ->power_on() callback, before the ->set_performance_state() has been invoked. And finally, the power domain may be turned off even if there are some active votes for a performance state. So for now, the genpd provider needs to deal with these cases. Yes, we have discussed changing the behaviour in genpd around this and I think there have been some good reasons for it, but we are not there, at least yet. [...] Kind regards Uffe