[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAE-0n502u+7CNhA5_kMfc-CVvpSzdGOeputT6nxW8BvtyVBeRQ@mail.gmail.com>
Date: Thu, 8 Jul 2021 00:23:16 +0000
From: Stephen Boyd <swboyd@...omium.org>
To: Andy Gross <agross@...nel.org>,
Bjorn Andersson <bjorn.andersson@...aro.org>,
Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
Rajendra Nayak <rnayak@...eaurora.org>,
Ulf Hansson <ulf.hansson@...aro.org>
Cc: linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RESEND PATCH 2/2] soc: qcom: rpmhpd: Make power_on actually
enable the domain
Quoting Bjorn Andersson (2021-07-02 19:54:49)
> 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.
s/turn/turned/
>
> 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@...aro.org>
> ---
Reviewed-by: Stephen Boyd <swboyd@...omium.org>
Powered by blists - more mailing lists