13:47 <aka_[m]> konradybcio: what are these "shared" rcgs?

13:53 <konradybcio> aka_: commit 7ef6f11887bd3676fc64517ca685f613d7f230ef

14:04 <aka_[m]> konradybcio damn, being so dumb hurts, i get 50/50 there

14:04 <aka_[m]> i just get that there is some main rcg and it can have rcgs(child mux/divs) and there is possibility that one of these childs might be controlled by TZ lets say?

14:05 <konradybcio> yes that's the whole point

14:05 <aka_[m]> then tz could control main rcg?

14:05 <konradybcio> On ds it's called safe config

14:05 <aka_[m]> konradybcio: oh shit i was trying to figure harder when porting 8953 to 4.19

14:06 <aka_[m]> i noticed this flag was translated to that once adding dispcc for 6115

14:06 <aka_[m]> i wonder, on 3.18 there is no such flag

14:07 <aka_[m]> any idea if they do it in different way?

14:07 <aka_[m]> msm8937 also had no such flags on 3.18/4.9 but 4.19 sdm439 gcc does have it

14:16 <konradybcio> no clue, i've been free of <msm-4.x for some time..

14:17 <aka_[m]> Heh

16:39 <aka_[m]> konradybcio: for patches can i base on qcom/linux.git instead of waiting for next to be updated?

16:39 <konradybcio> if it only touches things that are covered by qcom/linux.git, sure

16:39 <aka_[m]> dts alone

16:59 <aka_[m]> konradybcio: would you mind taking a look?:

16:59 <aka_[m]> https://github.com/Kiciuk/linux/commits/msm8953-rprocs-clean

16:59 <aka_[m]> still have to compile-test and binding checks

17:39 <djakov> konradybcio: hey, i discussed the QoS stuff with with some qcom folks and they confirmed that writing to QoS registers is persistant (they are reset only by the primary chip reset, they are retained during power collapse etc.), so we can program them just once, and not on every bandwidth request.

17:54 <aka_[m]> interconnect moment i see

17:56 <aka_[m]> konradybcio: when sending patches?

17:56 <aka_[m]> i might depend on .channels prop

18:41 <djakov> the support for specifying channel num should be already in -next

18:56 <aka_[m]> <djakov> "the support for specifying..." <- imma just have a look, regarding icc, do you know why some nodes return -6 error during probe?

18:58 <aka_[m]> ones with weird names like mas_spdm/mas_dehr

19:03 <djakov> on which platform is this?

19:04 <aka_[m]> 8976

19:05 <aka_[m]> last time i tested year ago

19:05 <aka_[m]> so maybe something changed

19:05 <aka_[m]> need to wire it again

19:08 <aka_[m]> prob something like this

19:08 <aka_[m]> https://github.com/torvalds/linux/commit/7ab1e9117607485df977bb6e271be5c5ad649a4c

19:08 <djakov> spdm is a debug thing, mostly used during board bringup and testing. not really useful upstream. recently we also removed the spdm from clock drivers

19:10 <aka_[m]> on very old source i have comments for each where i had errors:

19:10 <aka_[m]> https://github.com/Kiciuk/linux/blob/b03aaeec0dbadcd7c455d72a0d4c4ed27fbfd6a2/drivers/interconnect/qcom/msm8976.c

19:10 <aka_[m]> dehr/lpass/spdm/xm_usb_hs

19:10 <aka_[m]> i guess as long as we don't request any of these it won't make diff if they even exist in driver?

19:10 <aka_[m]> or by default it sends some request for each during probe?

19:16 <djakov> by default we go through each node and try to set initial bandwidth

19:19 <aka_[m]> i see.

19:19 <aka_[m]> so it would be better to drop node or just set rpm/slave ids to -1?

19:19 <djakov> well if the RPM complains about these mas/slv ids, then we should send them.. maybe these are not supported. odd that they exist in downstream.

19:21 <djakov> set the ids to -1. they may still be part of some path and removing them may break it...

19:24 <aka_[m]> based on pmos glossary page dehr is "DMA Engine for Hardware Retention"

21:13 <DavidHeidelberg[m]> anyone managed to upload kernel, initramfs over tftp to HDK 888?