• Abel Vesa's avatar
    PM: domains: Reverse the order of performance and enabling ops · ae8ac196
    Abel Vesa authored
    The ->set_performance_state() needs to be called before ->power_on()
    when a genpd is powered on, and after ->power_off() when a genpd is
    powered off. Do this in order to let the provider know to which
    performance state to power on the genpd, on the power on sequence, and
    also to maintain the performance for that genpd until after powering off,
    on power off sequence.
    
    There is no scenario where a consumer would need its genpd enabled and
    then its performance state increased. Instead, in every scenario, the
    consumer needs the genpd to be enabled from the start at a specific
    performance state.
    
    And same logic applies to the powering down. No consumer would need its
    genpd performance state dropped right before powering down.
    
    Now, there are currently two vendors which use ->set_performance_state()
    in their genpd providers. One of them is Tegra, but the only genpd provider
    (PMC) that makes use of ->set_performance_state() doesn't implement the
    ->power_on() or ->power_off(), and so it will not be affected by the ops
    reversal.
    
    The other vendor that uses it is Qualcomm, in multiple genpd providers
    actually (RPM, RPMh and CPR). But all Qualcomm genpd providers that make
    use of ->set_performance_state() need the order between enabling ops and
    the performance setting op to be reversed. And the reason for that is that
    it currently translates into two different voltages in order to power on
    a genpd to a specific performance state. Basically, ->power_on() switches
    to the minimum (enabling) voltage for that genpd, and then
    ->set_performance_state() sets it to the voltage level required by the
    consumer.
    
    By reversing the call order, we rely on the provider to know what to do
    on each call, but most popular usecase is to cache the performance state
    and postpone the voltage setting until the ->power_on() gets called.
    
    As for the reason of still needing the ->power_on() and ->power_off() for a
    provider which could get away with just having ->set_performance_state()
    implemented, there are consumers that do not (nor should) provide an
    opp-table. For those consumers, ->set_performance_state() will not be
    called, and so they will enable the genpd to its minimum performance state
    by a ->power_on() call. Same logic goes for the disabling.
    Signed-off-by: default avatarAbel Vesa <abel.vesa@linaro.org>
    Reviewed-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
    ae8ac196
domain.c 84.4 KB