06:31 <krzk> aka_[m]: you need functions (and name it meaningfully, not "pinconf")

08:06 <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

08:15 <krzk> aka_[m]: such syntax was entirely removed a cycle or two cycles ago.

08:15 <krzk> mux and config go always to same node

08:16 <aka_[m]> Ok so I will move props into wlanx then

11:33 <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.

11:34 <Guest6554> See https://lore.kernel.org/linux-arm-msm/61e8c730-e46d-728d-d770-f1ead4405d12@quicinc.com/

11:34 <konradybcio> is BIMC also fixed?

11:36 <Guest6554> I don't know (and don't think so).

11:37 <Guest6554> Anyway, the frequencies are strange.

11:39 <konradybcio> actually, I re-read the message.. the clocks in the GCC block should not be handled by interconnect

11:39 <konradybcio> they will probably need to be enabled before setting QoS registers from therein, but generally they are handled from device drivers

11:39 <Guest6554> Hmm.

11:40 <konradybcio> the message says that the USB<->[AS]NoC clocks are fixed, not the buses themselves

11:40 <konradybcio> which makes more sense ;)

11:41 <lumag> somehow the nick was lost

11:41 <lumag> konradybcio, I feel kind of strange if the the USB drives the anoc/snoc clocks

11:42 <lumag> Might it be related to your non-bus clocks?

11:42 <konradybcio> I mean, we've had things like GCC_AGGRE_NOC_PCIE_TBU_CLK before

11:43 <konradybcio> or more obviously, GCC_GPU_MEMNOC_GFX_CLK

11:43 <konradybcio> it probably matters more that these clocks are enabled at all

11:43 <lumag> Yes.

11:44 <lumag> It is actually the assignment of the rates that triggered my question

11:45 <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

11:45 <konradybcio> so that the clocks are actually disabled when unused

11:45 <lumag> I see

11:45 <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

11:45 <lumag> konradybcio, And this puts r->enabled out of sync with core->enabled_count

11:46 <konradybcio> well, most of these clocks come enabled from the bootloader, so we can't really rely on enabled_count anyway

11:47 <lumag> And anyway, there are enabled by the handoff

11:47 <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

11:48 <konradybcio> yes, they are enabled but it was never represented and so they all were enabled and voted for FMAX

11:48 <konradybcio> and that's why adding an icc driver always caused a sudden drop in performance

11:48 <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?

11:49 <lumag> This also looks like a hack though

11:49 <konradybcio> wouldn't that call the enable func again, voting for FMAX once more?

11:49 <lumag> ok, with the r->enabled being set to true in handoff at least the is_enabled part makes sense

11:50 <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

11:50 <lumag> I don't know too

11:51 <konradybcio> fwiw i like the IS_CRITICAL part

11:52 <lumag> I think clk_is_enabled { return r->enabled; } and IS_CRITICAL would be good enough

11:52 <lumag> I'm not sure about the gain of is_prepared

11:57 <konradybcio> well I suppose it will get handled by clk_disable_unused_subtree or clk_unprepare_unused_subtree either way

12:05 <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..

12:06 <lumag> konradybcio, so, regarding these noc clocks, do we understand what do they drive? Do they clock the device <-> NoC interface or something else?

12:07 <konradybcio> that seems to be the only logical explanation, either the direct device<->NoC connection or with some anonymous middleman

12:09 <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.

12:10 <lumag> And of course a device-only GCC_AGGRE_NOC_PCIE_TBU_CLK (not a part of the bus config).

12:11 <lumag> I have a weak guess, that some (all?) of these clocks should be enabled if the end-device votes on a bandwidth.

12:11 <lumag> And can be disabled if the vote is removed.

12:11 <lumag> djakov, bamse you opinion would valued here ^^

12:41 <konradybcio> lumag: guess what, the ipa clock crashing stuff was becuase of icc..

12:42 <lumag> how is that?

12:42 <konradybcio> fun how the node dependencies aren't properly described anywhere

12:42 <konradybcio> there are like 2 or 3 ipa nodes

12:42 <konradybcio> some qos vote was cast

12:42 <konradybcio> the platform crashed (unclocked access)

12:42 <lumag> I see

12:42 <konradybcio> i knocked off qos voting and now it works.. arghhhh...

12:43 <lumag> It looks like we have to have the per-node clocks

12:43 <konradybcio> yep i mentioned that somewhere last week I believe.. the sad thing being, the only way to find them is through educated guesses

12:44 <konradybcio> or well, bruteforcing.. but i'm not booting a device num_clock + num_clock-1 + ... + num_clock times

12:55 <lumag> Ugh

12:55 <lumag> Is this info present in vendor dts?

12:55 <lumag> I see that some bus nodes contain node clocks

13:08 <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.

13:10 <konradybcio> lumag: on msm5.4 the msmbus moved away from dts

13:10 <konradybcio> now it's all guesstimates

13:33 <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)

17:17 <Mis012[m]> wait a minute... the downstream driver is writing in the void?

17:19 <aka_[m]> first time?

18:36 <aka_[m]> any idea when qcom/linux going to have any action going on?

18:36 <aka_[m]> its bit stale still

18:37 <aka_[m]> i seen it doing something like after rc2/3 last time

18:39 <konradybcio> rc1 was released yesterday, chill

20:21 <Mis012[m]> nice nice nice

20:31 <steev> it's generally... rc1 -> testing -> activities

20:57 <aka_[m]> <steev> "it's generally... rc1 -> testing..." <- good to know, thanks

20:59 <steev> gotta fix the breakages (if any) so releases don't release broken ;)