From: Stephen Boyd <sboyd@kernel.org>
To: Md Sadre Alam <quic_mdalam@quicinc.com>,
andersson@kernel.org, bhupesh.sharma@linaro.org,
linux-arm-msm@vger.kernel.org, linux-clk@vger.kernel.org,
linux-kernel@vger.kernel.org, mturquette@baylibre.com,
quic_anusha@quicinc.com
Cc: quic_mdalam@quicinc.com, quic_srichara@quicinc.com,
quic_varada@quicinc.com, stable@vger.kernel.org
Subject: Re: [PATCH v2] clk: qcom: gcc-ipq9574: Add BRANCH_HALT_VOTED flag
Date: Mon, 06 May 2024 17:04:35 -0700 [thread overview]
Message-ID: <ee18e89b77f0c08ef45cbcc75e2361bf.sboyd@kernel.org> (raw)
In-Reply-To: <20240506063751.346759-1-quic_mdalam@quicinc.com>
Quoting Md Sadre Alam (2024-05-05 23:37:51)
> Add BRANCH_HALT_VOTED flag to inform clock framework
> don't check for CLK_OFF bit.
>
> CRYPTO_AHB_CLK_ENA and CRYPTO_AXI_CLK_ENA enable bit is
> present in other VOTE registers also, like TZ.
> If anyone else also enabled this clock, even if we turn
> off in GCC_APCS_CLOCK_BRANCH_ENA_VOTE | 0x180B004, it won't
> turn off.
> Also changes the CRYPTO_AHB_CLK_ENA & CRYPTO_AXI_CLK_ENA
> offset to 0xb004 from 0x16014.
How about this?
The crypto_ahb and crypto_axi clks are hardware voteable. This means
that the halt bit isn't reliable because some other voter in the
system, e.g. TrustZone, could be keeping the clk enabled when the
kernel turns it off from clk_disable(). Make these clks use voting mode
by changing the halt check to BRANCH_HALT_VOTED and toggle the voting
bit in the voting register instead of directly controlling the branch
by writing to the branch register. This fixes stuck clk warnings seen
on ipq9574 and saves power by actually turning the clk off.
>
> Cc: stable@vger.kernel.org
> Fixes: f6b2bd9cb29a ("clk: qcom: gcc-ipq9574: Enable crypto clocks")
> Signed-off-by: Md Sadre Alam <quic_mdalam@quicinc.com>
next prev parent reply other threads:[~2024-05-07 0:04 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-06 6:37 [PATCH v2] clk: qcom: gcc-ipq9574: Add BRANCH_HALT_VOTED flag Md Sadre Alam
2024-05-07 0:04 ` Stephen Boyd [this message]
2024-05-09 10:44 ` Md Sadre Alam
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ee18e89b77f0c08ef45cbcc75e2361bf.sboyd@kernel.org \
--to=sboyd@kernel.org \
--cc=andersson@kernel.org \
--cc=bhupesh.sharma@linaro.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mturquette@baylibre.com \
--cc=quic_anusha@quicinc.com \
--cc=quic_mdalam@quicinc.com \
--cc=quic_srichara@quicinc.com \
--cc=quic_varada@quicinc.com \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox