15:22 <Mis012[m]> bryanodonoghue: uhm, even from EL3 writing to the nidnt mux register doesn't change the value...

15:22 <Mis012[m]> so presumably it's not a permission issue

15:22 <bryanodonoghue> dumb question - which SoC are you doing this on ? Mis012[m]

15:22 <Mis012[m]> msm8998

15:23 <Mis012[m]> msm8996 is the last one that I found downstream dts with nidnt stuff for

15:23 <Mis012[m]> and sdm845 already uses EUD stuff instead

15:23 <bryanodonoghue> lumag is doing 8996 stuff currently I think

15:24 <Mis012[m]> 8998 has the same TLMM_ETM_MODE register as 8996

15:24 <Mis012[m]> 8916 had pin stimulation support, that was nice :/

15:26 <lumag> I have never looked into ETM/coresight

15:26 <lumag> So I fear I'm of a little help here

15:26 <lumag> aka_[m], missed your message, please excuse me.

15:27 <Mis012[m]> lumag: writing that register should mux SWD to sdcard slot, but it refuses to change value

15:27 <lumag> It might be e.g. forbidden by fuses (being theoretic here)

15:27 <Mis012[m]> well, it could be, but for sure not on this device

15:28 <Mis012[m]> even writing that register in EL3 doesn't seem to do anything

15:28 <lumag> aka_[m], do you want to chance cci mux/freq from CPU clock notifier?

15:28 <lumag> Mis012[m], no idea then

15:28 <Mis012[m]> is it possible that the XPU is set to not allow writes even from EL3, despite presumably being owned by EL3?

15:29 <Mis012[m]> I guess it is in theory

15:30 <Mis012[m]> or the register is just hardwired to 0x0 as a troll

15:31 <aka_[m]> lumag: yea

15:31 <aka_[m]> its only one pll and rate is fixed

15:32 <lumag> aka_[m], I fear that you might fall into issues with CCF: either with locking or with properly updating the core structures

15:33 <aka_[m]> ccf?

15:33 <Mis012[m]> common clock framework?

15:33 <aka_[m]> uh i don't need to register CCI clock at all

15:34 <Mis012[m]> ugly

15:34 <aka_[m]> if i set cpu cluster to parent 5(dedicated pll) then just post_rate change i can set mux with clk-mux-div and fixed parent/div

15:35 <aka_[m]> its quite bothersome to have one pll and having clock framework trying to set different rates for different clusters parts

15:36 <aka_[m]> it has to recalc and redo all shit if main PLL rate gets changed

15:37 <aka_[m]> Mis012: sadly there isn't much what can be done

15:37 <aka_[m]> 632 atleast have separate CCI source

18:52 <minecrell> Mis012[m]: if you have a sb-off device you should probably run your code before the XPU are initialized, i.e. as early as possible in the boot chain

19:38 <Mis012[m]> minecrell: I'm happy enough with how early I can get EL3, can't get it any sooner sadly

19:39 <Mis012[m]> but I think XPUs are not write-once, so it should be possible to turn them off and they should all be owned by EL3 at this point

19:40 <Mis012[m]> I just find it peculiar that the XPU would be set to not even allow writes from it's owner

20:27 <minecrell> Mis012[m]: that doesn't sound very early, at least on msm8916 the xpu stuff seems to be only initialized by tz

20:28 <minecrell> so if qcom's tz is missing everything seems accessible

20:48 <Mis012[m]> well, it has to be initialized by XBL_SEC

20:48 <Mis012[m]> since otherwise SBL can access anything and that kills the point of splitting it in two