ChanServ changed the topic of #linux-msm to:
marvin24 has joined #linux-msm
marvin24_ has quit [Ping timeout: 480 seconds]
BobBeck is now known as Guest3236
BobBeck has joined #linux-msm
pespin has joined #linux-msm
<adomerle[m]> <Degdag_Med[m]> "dmm_20230611223806.txt" <- lumag: I have the same issue, but your patches had no effect
<aka_[m]> i have weird question
<aka_[m]> in clk-alpha-pll inside static struct clk_alpha_pll we have .enable_mask
<aka_[m]> does it override platform default?
<aka_[m]> i guess that filed goes into alpha_pll_configure
<aka_[m]> which use regwrite
<aka_[m]> damn i need 8953 TRM
<aka_[m]> ok
<aka_[m]> i see
<aka_[m]> clk-regmap it reads reg and flip bit
<aka_[m]> with operator
<konradybcio> sboyd: I found a funny corner case in clk.. if we have a clock marked as CLK_IS_CRITICAL and the clock provider is runtime_pm-enabled, it will never go to sleep.. I was thinking about ways of solving this.. CLK_POWERED_EXTERNALLY which would go through the pm_put functions but not unprepare?
<aka_[m]> hmm
<aka_[m]> still looks sad, can clock output be connected to external input block with static divider?
<aka_[m]> qcom does fuse some pll settings
<konradybcio> aka_: there's no enable_mask for alpha_pll
<aka_[m]> so why not
<aka_[m]> well
<aka_[m]> .clkr is clk-regmap
<aka_[m]> damn
<aka_[m]> now i get it
<konradybcio> aka_: some clocks are powered whenever power flows through the block.. but they never turn on when the system is in use
<minecrell> konradybcio: How can you have an always-on clock with a non-always on runtime pm/power domain/whatever runtime pm does there? Then it's not really always-on ("critical") anymore
<konradybcio> minecrell: there's some per-subsystem XO outputs within like gcc
<konradybcio> which are either always on or should be always-on
<minecrell> konradybcio: Sounds like you don't want them to be always-on but more like always-ungated? Always-on would also propagate a XO vote upwards, preventing proper sleep states
<konradybcio> minecrell: I don't see a difference between "on" and "ungated", unless by "on" you meant "enabled from linux POV"
<konradybcio> some drivers "deal" with that by hardcoding setting the EN bit in probe() but I really dislike this approach
<minecrell> konradybcio: well, CLK_IS_CRITICAL does "enable from linux POV" afaik. Does an "enable clock but I don't care about parents" (aka just ungating) exists in the CCF?
<minecrell> well, you can not declare a parent I guess
<konradybcio> minecrell: well linux doesn't have any parents for them
<konradybcio> yeah
<minecrell> Is it worth describing them at all then?
<konradybcio> I'm debating this..
<konradybcio> but I'd love to keep them around, if possible
<minecrell> Without a parent it's kind of a lie already so you wouldn't make it worse I'd say :p
<konradybcio> yeah well, hard not to agree here..
<konradybcio> wdyt bamse
<aka_[m]> lumag: back in time we were talking about early vs other outputs and question was if its always early being unmodified, now im looking into 8953 flat and it appears other outputs also can have their dividers configured, it probably depends on some variation of pll design.
<aka_[m]> GPLL3 on 8953 has these in user_reg AUX_POST_DIV_RATIO BIT[17:15] POST_DIV_RATIO BIT[11:8]
<aka_[m]> some fields in flats are like USER_RSVD4
<aka_[m]> not helpful at all
<aka_[m]> i guess user_reserved_group4
<aka_[m]> uppers are for SSC/fractional mode/dither(whatever it is)
<aka_[m]> the general purpose PLL i guess that why they are called gpll0 have bit different regs inside user compared to dedicated ones like one for cpu
<aka_[m]> ok fast read on 8953 GPLL3 user reg... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/hOpFYnfnZjwHUdEMXhXbeIwh>)
<aka_[m]> 8016 TRM
<aka_[m]> fused /2 post divider
<aka_[m]> i wonder if they can fuse output enable too
<aka_[m]> i guess thats what they do on gpll0
<aka_[m]> i guess if we read config of pll when calculating rate we could live without doing clk_fixed_factor for fused post_div
<aka_[m]> too dumb for this pll shit
<aka_[m]> gpll4 have some BIT(5) enabled which is undocumented
<aka_[m]> kamorta says its LVMST_EN
<aka_[m]> AUX2=BIST
<aka_[m]> other flat says DIFF_90/DIFF_0 i guess thats somehow shifted signal
<aka_[m]> gpll6 is even more wild, it does use output_inv which probably is transformation which should belong into pll config not enable
<aka_[m]> at this point i don't understand anymore, gpll6 on 8953 PLL_LOCK_DET BIT however this field for rest bits is on BIT(31) yet they utilize PLL_ACTIVE_FLAG BIT[30] instead
<aka_[m]> why on one pll we read PLL_LOCK_DET and on other PLL_ACTIVE_FLAG for "same" fields from clk-pll perspective
<aka_[m]> LOCK_DET sounds like field which gets emptied once PLL manage to lock on desired freq
<aka_[m]> i remember i seen such on clk-hfpll
<aka_[m]> hmm, maybe GPLL0-GPLL4 are idk how they call them FSM? and these are always somehow voted
<aka_[m]> reading gpll0_mode indeed shows some bias fields being populated together with PLL_VOTE_FSM_ENA and both lock/active bit being set to 1
<aka_[m]> oh my god, i know where these gpllX_mm2 comes from
<aka_[m]> specific _CFG_RCGR have hardcoded SRC_DIV
<aka_[m]> so SDCC2 is hardcoded with DIV2 and qcom just decided to mock fixed clock rate so you can just write SRC_SEL and be happy
<aka_[m]> wrong field, ok time to stop spamming
<konradybcio> Technical monologues are useful for others
<Degdag_Med[m]> <adomerle[m]> "lumag: I have the same issue..." <- I don't think it's the same issue , your panel is a video mode DSC panel so much different from cmd mode, along with that pll lock errors stiil showing for me
<Marijn[m]> Degdag_Med: it spams for me for quite a few iterations but eventually locks, on everything from sm8150 all the way up until sm8450
<Marijn[m]> And maybe also sdm845 and sm6xxx
<konradybcio> And sm6115 and qcm2290
<Degdag_Med[m]> <Marijn[m]> "Degdag_Med: it spams for me..." <- yeah me too
<Degdag_Med[m]> it locks after that errors spam
pespin has quit []
<aka_[m]> <konradybcio> "And sm6115 and qcm2290" <- so its not 7nm driver alone
<aka_[m]> haven't rebased lemon in a while tho
<aka_[m]> these issues are on next or current rc?
Guest3147 has quit [Remote host closed the connection]
Daanct12 has joined #linux-msm
<aka_[m]> konradybcio: is it normal that downstream almost park every single rcg to safe xo?
<aka_[m]> im slowly finishing 4.19 gcc for 8953 and on sdm429 almost every single rcg does .enable_safe_config
<aka_[m]> 5 clocks does not use it namely byteX/pclkX/gfx3d
<aka_[m]> any idea how to calculate alpha field value?
<aka_[m]> or how 64bit-width alpha looks like
<aka_[m]> ok i get it
<aka_[m]> 750=39+(X)*19.2
<aka_[m]> 750-748.8=1.2
<aka_[m]> 19.2/X=1.2
<aka_[m]> X=16
<aka_[m]> ok still wrong
<aka_[m]> what is a use of hws inside gcc?
<konradybcio> aka_: number of safe rcgs depends on the soc really
<konradybcio> hws let you register struct clk_hw like for fixed divs