<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]>
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