ChanServ changed the topic of #linux-msm to:
marvin24 has joined #linux-msm
marvin24_ has quit [Ping timeout: 480 seconds]
<krzk> aka_[m]: you need functions (and name it meaningfully, not "pinconf")
pespin has joined #linux-msm
pespin has quit []
pespin has joined #linux-msm
<aka_[m]> krzk: from snippet as you see these pins have functions defined above I just wanted to set their strength and bias within single node, seems like ij have to move these props into wlanX
<krzk> aka_[m]: such syntax was entirely removed a cycle or two cycles ago.
<krzk> mux and config go always to same node
<aka_[m]> Ok so I will move props into wlanx then
pevik_ has joined #linux-msm
pevik_ has quit []
pevik_ has joined #linux-msm
<Guest6554> djakov, (and also bamse, konradybcio): any opinion on the interconnects for the ipq9574? It is claimed that anoc/snoc run at the fixed speed (and thus do not need the icc driver), but I'm still feeling bad regarding referencing corresponding clocks from the end-device nodes and setting the frequencies manually.
<konradybcio> is BIMC also fixed?
<Guest6554> I don't know (and don't think so).
<Guest6554> Anyway, the frequencies are strange.
<konradybcio> actually, I re-read the message.. the clocks in the GCC block should not be handled by interconnect
<konradybcio> they will probably need to be enabled before setting QoS registers from therein, but generally they are handled from device drivers
<Guest6554> Hmm.
<konradybcio> the message says that the USB<->[AS]NoC clocks are fixed, not the buses themselves
<konradybcio> which makes more sense ;)
Guest6554 is now known as lumag
<lumag> somehow the nick was lost
<lumag> konradybcio, I feel kind of strange if the the USB drives the anoc/snoc clocks
<lumag> Might it be related to your non-bus clocks?
<konradybcio> I mean, we've had things like GCC_AGGRE_NOC_PCIE_TBU_CLK before
<konradybcio> or more obviously, GCC_GPU_MEMNOC_GFX_CLK
<konradybcio> it probably matters more that these clocks are enabled at all
<lumag> Yes.
<lumag> It is actually the assignment of the rates that triggered my question
<konradybcio> lumag: regarding my rpmcc patchset, I realized I sent it without one key ingredient: Shawn had a patch for assigning "r->enabled = true" in clk_smd_rpm_handoff() which makes all the difference
<konradybcio> so that the clocks are actually disabled when unused
<lumag> I see
<konradybcio> it also shows that the IPA clock should not be disabled or bad things will happen.. I'll re-evaluate all this and follow up soon
<lumag> konradybcio, And this puts r->enabled out of sync with core->enabled_count
<konradybcio> well, most of these clocks come enabled from the bootloader, so we can't really rely on enabled_count anyway
<lumag> And anyway, there are enabled by the handoff
<konradybcio> and the RPM uC is off-AP with no (?) easy way to get info about them being enabled, so tracking them manually in r->enabled seems like the logical choice
<konradybcio> yes, they are enabled but it was never represented and so they all were enabled and voted for FMAX
<konradybcio> and that's why adding an icc driver always caused a sudden drop in performance
<lumag> WDYT about calling clk_prepare_enabled (in handoff) /clk_disable_unprepare (somewhere during late init) for all the clocks, while marking keepalive clocks with IS_CRITICAL?
<lumag> This also looks like a hack though
<konradybcio> wouldn't that call the enable func again, voting for FMAX once more?
<lumag> ok, with the r->enabled being set to true in handoff at least the is_enabled part makes sense
<konradybcio> forgot to mention, downstream caches the rate and makes sure you don't vote for the same value twice, not sure if it's there so as not to overwhelm RPM (it only takes so many requests at a time and it's realtively slow) or for some erratum / don't-do-this reasons
<lumag> I don't know too
<konradybcio> fwiw i like the IS_CRITICAL part
<lumag> I think clk_is_enabled { return r->enabled; } and IS_CRITICAL would be good enough
<lumag> I'm not sure about the gain of is_prepared
<konradybcio> well I suppose it will get handled by clk_disable_unused_subtree or clk_unprepare_unused_subtree either way
<konradybcio> and I guess for this IPA kamikaze we could stick with .flags |= CLK_IGNORE_UNUSED, as we want to disable it down the line.. but then why would it complain about disabling it right away..
<lumag> konradybcio, so, regarding these noc clocks, do we understand what do they drive? Do they clock the device <-> NoC interface or something else?
<konradybcio> that seems to be the only logical explanation, either the direct device<->NoC connection or with some anonymous middleman
<lumag> I checked against 4.14. I see that some of AGGRE clocks are used as node clocks in the bus tree. And some (GCC_AGGRE_USB3_PRIM_AXI_CLK) are mentioned both in bus and in device config.
<lumag> And of course a device-only GCC_AGGRE_NOC_PCIE_TBU_CLK (not a part of the bus config).
<lumag> I have a weak guess, that some (all?) of these clocks should be enabled if the end-device votes on a bandwidth.
<lumag> And can be disabled if the vote is removed.
<lumag> djakov, bamse you opinion would valued here ^^
<konradybcio> lumag: guess what, the ipa clock crashing stuff was becuase of icc..
<lumag> how is that?
<konradybcio> fun how the node dependencies aren't properly described anywhere
<konradybcio> there are like 2 or 3 ipa nodes
<konradybcio> some qos vote was cast
<konradybcio> the platform crashed (unclocked access)
<lumag> I see
<konradybcio> i knocked off qos voting and now it works.. arghhhh...
<lumag> It looks like we have to have the per-node clocks
<konradybcio> yep i mentioned that somewhere last week I believe.. the sad thing being, the only way to find them is through educated guesses
nashpa has quit []
<konradybcio> or well, bruteforcing.. but i'm not booting a device num_clock + num_clock-1 + ... + num_clock times
dliviu has joined #linux-msm
<lumag> Ugh
<lumag> Is this info present in vendor dts?
<lumag> I see that some bus nodes contain node clocks
<djakov> lumag: thanks for the link. it sounds like this is for USB port that connects to the NOC. if bandwidth scaling is not needed (or other interconnect configuration), then maybe this can go without interconnect provider driver.
<konradybcio> lumag: on msm5.4 the msmbus moved away from dts
<konradybcio> now it's all guesstimates
<konradybcio> there are *some* entries in there but they're incomplete and downstream relies on not voting before the hardware "endpoint" has been prepared (clks, gdscs)
jessica_24 has joined #linux-msm
<Mis012[m]> wait a minute... the downstream driver is writing in the void?
<aka_[m]> first time?
<aka_[m]> any idea when qcom/linux going to have any action going on?
<aka_[m]> its bit stale still
<aka_[m]> i seen it doing something like after rc2/3 last time
<konradybcio> rc1 was released yesterday, chill
pespin has quit [Remote host closed the connection]
enok_ has joined #linux-msm
minecrell4 has joined #linux-msm
jnn has joined #linux-msm
BobBeck9 has joined #linux-msm
kholk0 has joined #linux-msm
pevik has quit [Remote host closed the connection]
enok has quit [Ping timeout: 480 seconds]
pevik_ has quit []
dv_ has quit []
BobBeck has quit []
kholk has quit []
minecrell has quit []
jn has quit []
kholk0 is now known as kholk
enok_ is now known as enok
dv_ has joined #linux-msm
BobBeck has joined #linux-msm
pevik_ has joined #linux-msm
jn has joined #linux-msm
minecrell has joined #linux-msm
minecrell has quit [Max SendQ exceeded]
BobBeck has quit [Ping timeout: 484 seconds]
jn has quit [Ping timeout: 484 seconds]
pevik has joined #linux-msm
pevik__ has joined #linux-msm
pevik_ has quit []
dv_ has quit []
dv_ has joined #linux-msm
minecrell4 has quit []
minecrell has joined #linux-msm
<Mis012[m]> nice nice nice
<steev> it's generally... rc1 -> testing -> activities
pevik__ has quit [Quit: Lost terminal]
<aka_[m]> <steev> "it's generally... rc1 -> testing..." <- good to know, thanks
<steev> gotta fix the breakages (if any) so releases don't release broken ;)
minecrell9 has joined #linux-msm
minecrell has quit []
dv_ has quit []
dv_ has joined #linux-msm
redscience has joined #linux-msm
redscience has quit []
minecrell9 has quit []
minecrell9 has joined #linux-msm