[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Yx9S/TGi2q+nozZo@google.com>
Date: Mon, 12 Sep 2022 15:40:45 +0000
From: Matthias Kaehlcke <mka@...omium.org>
To: Rajendra Nayak <quic_rjendra@...cinc.com>
Cc: andersson@...nel.org, agross@...nel.org,
konrad.dybcio@...ainline.org, mturquette@...libre.com,
sboyd@...nel.org, johan+linaro@...nel.org,
quic_kriskura@...cinc.com, dianders@...omium.org,
linux-clk@...r.kernel.org, linux-arm-msm@...r.kernel.org,
linux-kernel@...r.kernel.org,
AngeloGioacchino Del Regno
<angelogioacchino.delregno@...ainline.org>
Subject: Re: [PATCH 1/3] clk: qcom: gdsc: Fix the handling of PWRSTS_RET
support
On Thu, Sep 01, 2022 at 03:47:54PM +0530, Rajendra Nayak wrote:
> GDSCs cannot be transitioned into a Retention state in SW.
> When either the RETAIN_MEM bit, or both the RETAIN_MEM and
> RETAIN_PERIPH bits are set, and the GDSC is left ON, the HW
> takes care of retaining the memory/logic for the domain when
> the parent domain transitions to low power state.
> The existing logic handling the PWRSTS_RET seems to set the
> RETAIN_MEM/RETAIN_PERIPH bits but then explicitly turns the
> GDSC OFF as part of _gdsc_disable(). Fix that by leaving the
> GDSC in ON state.
>
> Signed-off-by: Rajendra Nayak <quic_rjendra@...cinc.com>
> Cc: AngeloGioacchino Del Regno <angelogioacchino.delregno@...ainline.org>
> ---
> There are a few existing users of PWRSTS_RET and I am not
> sure if they would be impacted with this change
>
> 1. mdss_gdsc in mmcc-msm8974.c, I am expecting that the
> gdsc is actually transitioning to OFF and might be left
> ON as part of this change, atleast till we hit system wide
> low power state.
> If we really leak more power because of this
> change, the right thing to do would be to update .pwrsts for
> mdss_gdsc to PWRSTS_OFF_ON instead of PWRSTS_RET_ON
> I dont have a msm8974 hardware, so if anyone who has can report
> any issues I can take a look further on how to fix it.
>
> 2. gpu_gx_gdsc in gpucc-msm8998.c and
> gpu_gx_gdsc in gpucc-sdm660.c
> Both of these seem to add support for 3 power state
> OFF, RET and ON, however I dont see any logic in gdsc
> driver to handle 3 different power states.
> So I am expecting that these are infact just transitioning
> between ON and OFF and RET state is never really used.
> The ideal fix for them would be to just update their resp.
> .pwrsts to PWRSTS_OFF_ON only.
So far nobody has reported back on this. What are the next steps?
If we want to confirm the actual behavior on those platforms
before landing this maybe you or Bjorn could try to locate
someone within QC with access to such systems.
> drivers/clk/qcom/gdsc.c | 10 ++++++++++
> drivers/clk/qcom/gdsc.h | 5 +++++
> 2 files changed, 15 insertions(+)
>
> diff --git a/drivers/clk/qcom/gdsc.c b/drivers/clk/qcom/gdsc.c
> index d3244006c661..ccf63771e852 100644
> --- a/drivers/clk/qcom/gdsc.c
> +++ b/drivers/clk/qcom/gdsc.c
> @@ -368,6 +368,16 @@ static int _gdsc_disable(struct gdsc *sc)
> if (sc->pwrsts & PWRSTS_OFF)
> gdsc_clear_mem_on(sc);
>
> + /*
> + * If the GDSC supports only a Retention state, apart from ON,
> + * leave it in ON state.
> + * There is no SW control to transition the GDSC into
> + * Retention state. This happens in HW when the parent
> + * domain goes down to a Low power state
> + */
> + if (sc->pwrsts == PWRSTS_RET_ON)
> + return 0;
> +
> ret = gdsc_toggle_logic(sc, GDSC_OFF);
> if (ret)
> return ret;
> diff --git a/drivers/clk/qcom/gdsc.h b/drivers/clk/qcom/gdsc.h
> index 5de48c9439b2..981a12c8502d 100644
> --- a/drivers/clk/qcom/gdsc.h
> +++ b/drivers/clk/qcom/gdsc.h
> @@ -49,6 +49,11 @@ struct gdsc {
> const u8 pwrsts;
> /* Powerdomain allowable state bitfields */
> #define PWRSTS_OFF BIT(0)
> +/*
> + * There is no SW control to transition a GDSC into
> + * PWRSTS_RET. This happens in HW when the parent
> + * domain goes down to a low power state
> + */
> #define PWRSTS_RET BIT(1)
> #define PWRSTS_ON BIT(2)
> #define PWRSTS_OFF_ON (PWRSTS_OFF | PWRSTS_ON)
> --
> 2.17.1
>
Powered by blists - more mailing lists