ChanServ changed the topic of #linux-msm to:
<lumag> aka_[m], are you questioning the read? In other words 799 instead of pure 800? this is 0.125%. I'd say this is normal
<lumag> so, if anything depends on the PLL reporting 800 instead of 799 it's broken by design
marvin24_ has joined #linux-msm
marvin24 has quit [Ping timeout: 480 seconds]
jhovold has joined #linux-msm
<aka_[m]> bryanodonoghue: do you get proper rate set for CCI on mainline?
<aka_[m]> I followed your way of adding CCI mux as assigned-clocks with assigned-clock-rates to core mux and it somehow went retard and set alpha-pll as primary source of CCI block without setting any divider.
<aka_[m]> In short i pumped 1.2Ghz into CCI block where ds max freq appears to be at 800Mhz.....
<aka_[m]> lumag: any idea why mux_div driver might allow doing that?
<aka_[m]> is there any chance to providing min/max rate to avoid such situations?
<aka_[m]> issue is on 8953 one PLL is to rule them all
<aka_[m]> 632 have dedicated PLL for CCI use
jhovold has quit [Ping timeout: 480 seconds]
<lumag> aka_[m], if you are using assigned-clock-rates, you can also add assigned-clock-parents
<aka_[m]> lumag: i don't really understand how these work, is it like if you do... (full message at <>)
<aka_[m]> and assigned-clock-parents reffers to parent of assigned-clock?
<lumag> yes
<aka_[m]> so parent should be &gcc GPLL0_EARLY ?
<aka_[m]> i mean assigned-clock-parent
<aka_[m]> im not sure if there is a way to make clk_mux_div set static divider value when switching to dedicated pll
<aka_[m]> we cannot really set specific rate there because its tied to PLL
<lumag> aka_[m], I'm not sure about GPLL0_EARLY.
<lumag> It it the clock you are passing to apcs_glb?
<aka_[m]> yes
<lumag> apcs_whatever
<aka_[m]> as "aux"
<lumag> then yes
<aka_[m]> on 8953 it uses alpha_ro ops
<aka_[m]> qcom pll situation is quite weird to me, big mess everywhere.
<aka_[m]> only qcom guys might know whats going on there.
<lumag> he-he
<lumag> aka_[m], but as far as I see, gpll0_early is also alpha_pll_fixed
<aka_[m]> i was quite mislead by downstream saying something about hwfsm ops
<aka_[m]> these exist on mainline in alpha-pll
<lumag> for gpll0?
<lumag> That would be strange. I don't know your platform, but I think usually gpll0 is fixed factor
<aka_[m]> on downstream duplicated between alpha-pll and clk-pll.
<aka_[m]> no for cpu pll
<lumag> cpu pll can be hwfsm (I didn't peek at downstream)
<aka_[m]> <lumag> "cpu pll can be hwfsm (I didn't..." <- issue is ops in clk-pll.c did pretty much nothing.
<aka_[m]> Not even writing into MODE register
<aka_[m]> like even enable/disable for pll was pretty much writing zero to some unrelated register and then udelay().
<aka_[m]> tomorrow will try this CCI thing. and if it somehow manage to not die i might just send it
<lumag> But that's a53 pll, not the alpha pll
<aka_[m]> uh on 8953 its alpha_pll
<aka_[m]> for apss
<aka_[m]> yet ds define ops in clk-pll.c
<aka_[m]> tried with Huayra ops but it was sad about something and cried about "clock needs to be gated" had to use default alpha ops
<aka_[m]> layout however looks like huayra
<aka_[m]> a53pll is pretty missleading name
<aka_[m]> its assigned to PLL found in 8916 which qcom calls "SR2"
<aka_[m]> this pll also supply a7 cores on 8909 so why not a7pll
<Mis012[m]> bamse: so I was remembering wrong... the issue with the TLMM_ETM_MODE register is that I can read it, I can write it, but writing it doesn't change the value
<Mis012[m]> I found the correct order for enabling all the qdss clocks, and now I can read the TPIU registers mentioned here:
<Mis012[m]> however writing them somehow also has no effect
<Mis012[m]> is there some qdss write lock somewhere...?
<Mis012[m]> this is really weird
<bryanodonoghue> aka_[m] what do you mean assigned clocks on the CCI ?
<bryanodonoghue> ping Fabien Parent
<bryanodonoghue> maybe he can share the working tree with you
<bryanodonoghue> assuming 8953 works like 404/405 and 8939 you need to pull a whole bunch of voltage compensations out of eeprom
<bryanodonoghue> and apply the right one for the freq you run the bus at
<bryanodonoghue> anyway just doing the CCI sounds like it won't work too well
<bryanodonoghue> you want to ramp the cluster(s) too
<bryanodonoghue> and IMO the AHB bus for the mdss path
<bryanodonoghue> at at least set that bus to max
<Mis012[m]> you mean fuses?
<Mis012[m]> qcom's fuses are not eeprom :P
<bryanodonoghue> fuses
<bryanodonoghue> yeah the regulator for the core is on i2c tho afair
<bryanodonoghue> which makes my brain say eeprom
<Mis012[m]> fun
<Mis012[m]> bryanodonoghue: any idea why TLMM_ETM_MODE is not reacting to writes?
<Mis012[m]> bryanodonoghue: at least up to 8996 I can find downstream devicetrees mentioning software switched nidnt
<Mis012[m]> 8998 not so much, but the same registers still exist
<Mis012[m]> 845 seems to have rebranded to EUD
<bryanodonoghue> tlmm etm mode ?
<bryanodonoghue> coresight ?
<bryanodonoghue> afraid not