Messages in this thread | | | Date | Fri, 10 Mar 2023 16:47:46 +0000 | Subject | Re: [PATCH v7 6/9] interconnect: qcom: rpm: Handle interface clocks | From | Bryan O'Donoghue <> |
| |
On 10/03/2023 14:26, Konrad Dybcio wrote: > > > On 10.03.2023 15:21, Bryan O'Donoghue wrote: >> On 08/03/2023 21:40, Konrad Dybcio wrote: >>> Some (but not all) providers (or their specific nodes) require >>> specific clocks to be turned on before they can be accessed. Failure >>> to ensure that results in a seemingly random system crash (which >>> would usually happen at boot with the interconnect driver built-in), >>> resulting in the platform not booting up properly. >> >> Can you give an example of which clocks on which SoC's ? > See for example 67fb53745e0b > > This was a clock documented downstream under the node-qos clocks here: > > https://github.com/sonyxperiadev/kernel/blob/aosp/LA.UM.5.7.r1/arch/arm/boot/dts/qcom/msm8996-bus.dtsi#L102-L109 > > but there are occasions where such clocks are undocumented and downstream > skips them because it relies on them being on by miracle, such as the case > of MASTER_IPA and the IPA rpmcc clock on msm8998. Downstream has no > sync_state, so they would only set the QoS registers when the relevant > hardware was online, so the clocks were on already.
What switched the clocks on ? Presumably LK.
Is this a symptom of using a bootloader other than LK ? If you use the same bootloader, then why hasn't the bootloader/LK already set it up on your platform ?
>> >> Is the intention of this patch to subsequently go through *.dts *.dtsi and start to remove assigned-clocks ? >> >> Are we saying that currently there ought to be assigned-clocks for some of these NoC declarations ? > Not really, assigned-clocks are used for static ratesetting, see > for example dwc3 nodes where we need it to be fast enough for > HS/SS operation at all times (though that should have prooobably > been handled in the driver but it's a separate topic), I don't > think any of them were used to combat what this commit tries to.
I think you could use assigned-clocks for that ..
So its not part of your series but then presumably you have a follow-on patch for the 8998 dts that points your ->intf_clks at these then ?
clocks = <&clock_gcc clk_aggre2_noc_clk>, <&clock_gcc clk_gcc_ufs_axi_clk>, <&clock_gcc clk_gcc_aggre2_ufs_axi_clk>;
It seems like the right thing to do..
Still not clear why these clocks are off.. your bootchain ?
--- bod
| |