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. > > 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. Konrad > > --- > bod
