On 11/22/2023 3:53 PM, Dmitry Baryshkov wrote:
On Wed, 22 Nov 2023 at 12:19, Kathiravan Thirumoorthy
<quic_kathirav@xxxxxxxxxxx> wrote:
On 11/22/2023 3:42 PM, Krzysztof Kozlowski wrote:
On 22/11/2023 11:08, Kathiravan Thirumoorthy wrote:
On 11/21/2023 8:36 PM, Krzysztof Kozlowski wrote:
On 21/11/2023 15:30, Kathiravan Thirumoorthy wrote:
In commit 0dd3f263c810 ("clk: qcom: ipq5332: enable few nssnoc clocks in
Where is this commit coming from?
driver probe"), gcc_snoc_nssnoc_clk, gcc_snoc_nssnoc_1_clk,
gcc_nssnoc_nsscc_clk are enabled in driver probe to keep it always-on.
Implementation can change and for example bring back these clocks. Are
you going to change bindings? No, drop the patch.
Bindings should be dropped only in a few rare cases like clocks not
available for OS or bugs.
Thanks Krzysztof. Will drop this patch in V3.
One more question to understand further. In IPQ SoCs there are bunch of
coresight / QDSS clocks but coresight framework doesn't handle all
clocks. Those clocks are enabled in bootloader stage itself. In such
case, should I drop the clocks from both binding and driver or only from
driver?
That's not really the reason to drop them at all. Neither from driver,
nor from bindings. You should not rely on bootloader handling your clocks
Thanks, lets say if those clocks are not needed at all by OS since QDSS
is not used and needed only for the boot loaders to access the
corresponding address space, in such case what can be done? I
understand, at first those clocks should not have been added to the driver.
First, what is QDSS? Yet another acronym?
Qualcomm Debug Sub System - which compromises of various debug infra
like coresight, DCC and so on.
Second, if they are not used now, they can get used later.
Thanks. I will drop it from driver and leave the bindings as it is.
Thanks,
Kathiravan
