lkml.org 
[lkml]   [2021]   [Aug]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [RESEND PATCH 2/2] soc: qcom: rpmhpd: Make power_on actually enable the domain
    On Thu, 12 Aug 2021 at 15:21, Dmitry Baryshkov
    <dmitry.baryshkov@linaro.org> 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@linaro.org>
    > > ---
    > >
    > > 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

    \
     
     \ /
      Last update: 2021-08-13 11:46    [W:3.162 / U:1.608 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site