On 30.12.2021 15:06, Dmitry Baryshkov wrote:

On Thu, 30 Dec 2021 at 05:31, Konrad Dybcio
[off-list ref] wrote:

quoted

Just like in commit 05cf3ec00d460b50088d421fb878a0f83f57e262
("clk: qcom: gcc-msm8996: Drop (again) gcc_aggre1_pnoc_ahb_clk")
adding NoC clocks turned out to be a huge mistake, as they cause a lot of
issues at little benefit (basically only letting Linux know about their
children's frequencies), especially when mishandled or misconfigured.

I'm not against this patch, but it manifests another question to me:
should the NoC driver set these frequencies (as demanded), or are they
set by the hardware/RPM/etc and so are read-only to us?

The downstream driver [1] only seems to vote for 19.2 MHz on

p(c)noc_keepalive_a_clk and 40MHz on mmssnoc_ahb_a_clk and

not really care much about them otherwise in the (msm_)clk framework.


Interestingly, the voting-at-probe also seems to be true for 8916 [2],

and even more so for 8974 [3] which votes for CXO too, and I don't

think we handle it upstream.. Is it unnecessary, or did things always

work by miracle? Should we perhaps set it with assigned-clocks under

rpmcc in DT?


Otherwise, they seem to be handled by msm_bus's voter clocks, so in

our case that'll be interconnect's job. I had an old WIP driver somewhere,

but it had issues with some (well, many) paths.. I'll rebase it and try debugging

that.


Decoding ancient msm-3.10 code is not for the faint of heart, but I don't think

8994 or 8974 (which are similar in many ways) ever got a newer kernel release..


[..]


Konrad


[1] https://github.com/sonyxperiadev/kernel/blob/aosp/LA.BR.1.3.3_rb2.14/drivers/clk/qcom/clock-rpm-8994.c#L292


[2] https://github.com/sonyxperiadev/kernel/blob/aosp/LA.BR.1.3.3_rb2.14/drivers/clk/qcom/clock-rpm-8916.c#L168


[3] https://github.com/sonyxperiadev/kernel/blob/aosp/LA.BR.1.3.3_rb2.14/arch/arm/mach-msm/clock-rpm-8974.c