09:53 <aka_[m]> krzk: i see you are working on mailbox stuff, i have simple question.

09:53 <aka_[m]> I might want to start switching some data soon for 8953 to use apcs-msm8916 driver. might that conflict if we align 8953 fallback compatible to other socs like 6125?

10:12 <krzk> aka_[m]: I might not follow... apcs-msm8916 is not mailbox driver... or do you mean that 8953 mailbox will come now with clocks?

10:12 <krzk> aka_[m]: but the other compatibles (using 8953 as fallback in my patches) won't be switched?

10:12 <aka_[m]> krzk: in mailbox driver there is binding to .clk which point to clock controller driver

10:13 <aka_[m]> as long as top left compats are not dropped from driver it should be fine i think?

10:22 <krzk> should be fine bu tit also indicates that the newer models, which I made compatible with 8953, are actually not compatible - there is difference.

10:22 <krzk> aka_[m]: thanks for sharing it, I will make then 8953 as separate "family"

10:23 <aka_[m]> 8953 with 8976 can use apcs-msm8916 mux driver

10:24 <aka_[m]> i just wanted to switch .data in 8953 compatible to point to 8916

10:24 <aka_[m]> same for 8976 obv

10:25 <krzk> aka_[m]: yeah, I understand, but then none of other newer variants (8994, 8998, qcm2290, sdm660, sm4250 etc) should be compatible with it.

10:25 <aka_[m]> yup

10:25 <krzk> aka_[m]: The best if you send your patches now, so I will rebase on top of them.

10:25 <aka_[m]> not sure how is 8994 but its quite weird soc based on Konrad

22:44 <aka_[m]> konradybcio: any idea if there is any chance to get some more data on PLL used per design from that IPQ guy?

22:45 <konradybcio> i think it comes down to "hello i have this new soc i want to add support for, that's what the pdf said it's in there and my coworker confirmed it's okay"

22:47 <aka_[m]> konradybcio: its all missleading a lot, from what i see 8953 based on offsets also suports HUAYRA

22:47 <aka_[m]> are CTL and CTL_U like low and upper?

22:48 <aka_[m]> appears like that

22:48 <aka_[m]> i love how detailed are these descriptions, like really

22:49 <aka_[m]> config_ctl on these legacy had a lot of technicals to it,

22:49 <aka_[m]> user one is quite easy on the other hand

22:51 <aka_[m]> tho im not sure about these flags about support of dynamic update, its something about being able to change freq on flight with just toggling some bits around without power-off and initialization right

22:53 <aka_[m]> ok mode register desc looks quite poor... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/WiVCyzhRpaMSQTMEbpSrTMIC>)

22:54 <aka_[m]> obv we all know it isn't all just qcom being lazy

22:56 <aka_[m]> worst thing is ds code appears to like hwfsm pll ops

22:57 <aka_[m]> hw managed FSM mode

22:57 <aka_[m]> sounds like that, should take a look at 8916 docs it has to have something

23:33 <konradybcio> _U is upper for 64bit registers yes

23:37 <aka_[m]> nice to see DS having different HWFSM ops for clk-pll and clk-alpha-pll, 8953 cpu clk using first one while in reality featuring alpha one.

23:38 <konradybcio> HW FSM is a hardware feature, not a clock type

23:38 <aka_[m]> i see it toggles some bits on alpha-pll driver

23:38 <aka_[m]> it does nothing besides disabling some test mode for 8953

23:38 <aka_[m]> which isnt even enabled by default

23:38 <konradybcio> downstream drivers can lie

23:38 <aka_[m]> even disable pll does not toggle mode register

23:38 <konradybcio> or make assumptions that never made it to final hw

23:39 <aka_[m]> it just disable test bits ->udelay(1)

23:39 <aka_[m]> how is that supposed to shut pll off

23:39 <aka_[m]> maybe we shouldn't?

23:40 <konradybcio> hwfsm does that for you

23:40 <konradybcio> or so i think