On 30.12.2021 15:06, Dmitry Baryshkov wrote:
> On Thu, 30 Dec 2021 at 05:31, Konrad Dybcio
> <konrad.dybcio@xxxxxxxxxxxxxx> wrote:
>> 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
