12:09 <aka_[m]> wrong place to ask but whatever:

12:09 <aka_[m]> Do anyone know what kind be reason for rpm-smd-regulator(downstream) to not probe vregs at all?

12:10 <aka_[m]> it ends in some weird loop where probing gets broken and stuff probe without dependencies being up

15:34 <ajhalaney[m]> konradybcio: bamse if you guys do find that Taniya's patch has some truth in it (i.e. set_rate + enable results in a different rate than expected)... please let me know! I basically made stmmac do that wrt a PTP clock, and I have no way of actually testing any of it. some QC folks said it worked, but I'm not entirely sure what they actually tested.

16:48 <bamse> ajhalaney[m]: are you saying that the problem description matches the problem you described in stmmac? (and that you worked around it in the driver?)

17:26 <ajhalaney[m]> bamse: no, rather the driver would encounter that problem if it exists, and I unfortunately had no way to test the affected feature so I couldn't find out if it did hit that problem description or not.

17:28 <bamse> ajhalaney[m]: remind me, what is the sequence the driver performs?

17:29 <bamse> -?

17:32 <ajhalaney[m]> devm_clk_get() + clk_set_rate() + clk_prepare_enable() on an RCG2 based clock bamse

17:35 <ajhalaney[m]> And it uses that clock as reference for a PTP related counter. You tell it how long till it rolls over and it timestamps packets with it iiuc. So you have to know what rate the clock is at, and the faster it runs, the finer resolution your timestamping is. IIUC from Taniya's patch they were saying a call to clk_get_rate() would return whatever you programmed, but it would not actually be in effect at the end of that sequence, which would

17:35 <ajhalaney[m]> then make the PTP programming bogus

17:58 <bamse> ajhalaney[m]: and the problem is that clk_prepare_enable() overwrites/ignore the clk_set_rate() right?

18:01 <ajhalaney[m]> A following clk_get_rate() equates to clk_set_rate(). I thought Taniya's patch description was saying that would be the case, but in hardware it wouldn't be the case, so effectively clk_set_rate() never happened. I can't test PTP (it is in a lab, not to mention I would need to figure out how :P), so I was trying to get ahead of the game on someone later telling me "hey this doesn't work"

18:08 <bamse> i think the clk_set_rate() will reconfigure the hardware, and then the clk_prepare will overwrite that configuration...

18:08 <bamse> and i think Taniya's patch solved that

18:08 <bamse> but iirc it wasn't based on the upstream kernel...

18:36 <ajhalaney[m]> So, you're saying you believe that if I did devm_clk_get(), initial_rate = clk_get_rate(), clk_set_rate(ideal_rate): the end result would be hardware running at initial_rate (or at least != ideal_rate), but the clk framework would still show ideal_rate as the current rate?

18:37 <ajhalaney[m]> I had thought with your last reply + no response from Taniya that it was maybe an issue in the past, but fixed upstream already. I guess I could program that counter I mentioned a little smarter and extrapolate what the real clock rate is of hardware (or figure out how to read that back directly in clk-rcg2) to verify if its true

20:40 <aka_[m]> how does that snippet work?

20:41 <aka_[m]> wait

20:42 <aka_[m]> wrong room, was supposed to be sent to MSM8953 mainline lol

20:42 <aka_[m]> obv negation of both checks then AND resulting in final check

20:45 <konradybcio> de morgan's law/identity

20:50 <aka_[m]> if both does not exist it will return enoent it seems