ChanServ changed the topic of #linux-msm to:
dliviu has quit [Ping timeout: 480 seconds]
dliviu has joined #linux-msm
marvin24_ has joined #linux-msm
marvin24 has quit [Ping timeout: 480 seconds]
nashpa has joined #linux-msm
dliviu has quit [Ping timeout: 480 seconds]
pevik_ has joined #linux-msm
pevik_ has quit []
pevik_ has joined #linux-msm
dliviu has joined #linux-msm
nashpa has quit [Ping timeout: 480 seconds]
svarbanov has quit [Read error: Connection reset by peer]
svarbanov has joined #linux-msm
<aka_[m]> krzk: i see you are working on mailbox stuff, i have simple question.
<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?
<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?
<krzk> aka_[m]: but the other compatibles (using 8953 as fallback in my patches) won't be switched?
<aka_[m]> krzk: in mailbox driver there is binding to .clk which point to clock controller driver
<aka_[m]> as long as top left compats are not dropped from driver it should be fine i think?
<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.
<krzk> aka_[m]: thanks for sharing it, I will make then 8953 as separate "family"
<aka_[m]> 8953 with 8976 can use apcs-msm8916 mux driver
<aka_[m]> i just wanted to switch .data in 8953 compatible to point to 8916
<aka_[m]> same for 8976 obv
<krzk> aka_[m]: yeah, I understand, but then none of other newer variants (8994, 8998, qcm2290, sdm660, sm4250 etc) should be compatible with it.
<aka_[m]> yup
<krzk> aka_[m]: The best if you send your patches now, so I will rebase on top of them.
<aka_[m]> not sure how is 8994 but its quite weird soc based on Konrad
svarbanov has quit [Ping timeout: 480 seconds]
svarbanov has joined #linux-msm
pg12_ has joined #linux-msm
pg12 has quit [Ping timeout: 480 seconds]
pespin has joined #linux-msm
pevik_ has quit [Ping timeout: 480 seconds]
svarbanov_ has joined #linux-msm
svarbanov has quit [Read error: Connection reset by peer]
Daaanct12 has quit [Quit: Quitting]
Danct12 has joined #linux-msm
pespin has quit [Remote host closed the connection]
Daanct12 has joined #linux-msm
Danct12 has quit [Ping timeout: 480 seconds]
Daaanct12 has joined #linux-msm
Daanct12 has quit [Ping timeout: 480 seconds]
<aka_[m]> konradybcio: any idea if there is any chance to get some more data on PLL used per design from that IPQ guy?
<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"
<aka_[m]> konradybcio: its all missleading a lot, from what i see 8953 based on offsets also suports HUAYRA
<aka_[m]> are CTL and CTL_U like low and upper?
<aka_[m]> appears like that
<aka_[m]> i love how detailed are these descriptions, like really
<aka_[m]> config_ctl on these legacy had a lot of technicals to it,
<aka_[m]> user one is quite easy on the other hand
<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
<aka_[m]> ok mode register desc looks quite poor... (full message at <>)
<aka_[m]> obv we all know it isn't all just qcom being lazy
<aka_[m]> worst thing is ds code appears to like hwfsm pll ops
<aka_[m]> hw managed FSM mode
<aka_[m]> sounds like that, should take a look at 8916 docs it has to have something
<konradybcio> _U is upper for 64bit registers yes
<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.
<konradybcio> HW FSM is a hardware feature, not a clock type
<aka_[m]> i see it toggles some bits on alpha-pll driver
<aka_[m]> it does nothing besides disabling some test mode for 8953
<aka_[m]> which isnt even enabled by default
<konradybcio> downstream drivers can lie
<aka_[m]> even disable pll does not toggle mode register
<konradybcio> or make assumptions that never made it to final hw
<aka_[m]> it just disable test bits ->udelay(1)
<aka_[m]> how is that supposed to shut pll off
<aka_[m]> maybe we shouldn't?
<konradybcio> hwfsm does that for you
<konradybcio> or so i think